Node.js async vs Java, what's the catch?

Question

Java

Good afternoon, help me understand, I read:

What is the advantage of Node?
Node is easier to scale. With thousands of users connected to the server at the same time, Node works asynchronously, that is, it prioritizes and allocates resources more intelligently. Java, for example, allocates a separate thread for each connection.

(if you need a source - google it, it doesn't allow you to insert links)
Firstly, it processes requests not from Node from Java, but from the server. Suppose we want to create a web service with a backend and a base. If we create in Java, then we install Nginx + Apache, and now Apache already allocates a worker for each request, which works synchronously, that is, it hangs during heavy queries to the database. Correctly I think?
Then the question is, how miraculously does Node avoid this? And what happens? Node runs on a V8 engine, which also needs a server like Nginx, right? If you can explain on your fingers, please, how everything happens there (and then I will read both Runet and bourgeois)? Well, it is asynchronous, but should someone make a request? Who makes it?
Well, in general, the quote above, is it true? or just campaigning for a node?

Answer 1

Well, firstly, Java has a lot of different greenlet and other technologies, where explicit asynchrony is not needed (it is inconvenient)
Secondly, separate workers in Apache are needed only for those backends that need it.
If you want to maximize the number of requests that can be executed in parallel by the backend, then obviously you need to look for another way, without Apache workers. For example, https://habrahabr.ru/company/itsumma/blog/337346/
Thirdly, for a better understanding, mentally isolate the task and generally exclude Apache here. We consider the possibilities of only the Node itself and the JVM itself.
Fourthly, holivar is absolutely meaningless, since a specific application will be implemented taking into account the capabilities of a specific execution environment. We are talking about quality implementation, of course. And the programmer will take into account the features of Noda or JVM. If he is qualified.
Fifth, no magic tool will help an unskilled programmer.
Sixth, ceteris paribus (with equally good knowledge of the programmer in both systems) - the JVM will always be faster. For she is not far behind S-something.
Seventh, but it is impossible not to pay attention to the fact that using the Node you can get by with the knowledge of one language. Actually, the rise of Noda is due to this. That there are a lot of front-end developers who want to write the back-end. And we have already written a bunch of auxiliary tools / libraries for it, etc. There is nothing more magical in Nod.

Answer 2

Sheer stupidity! At the moment: and for good, for at least 10 years, there are a bunch of asynchronous frameworks and network libraries that work exactly on the same principle as nodejs.
Examples, we have them:
- frameworks jooby.org, sparkjava, springboot
- libraries (servers) netty, undertow, akka
Performance is not inferior to nodejs.
Well, how does it all work? There are two types of programming that can be combined:
Old and widely used
- the server is waiting for a network connection
- as soon as the connection is made, the server starts a process / thread and passes an open connection to it.
In this case, we are limited by the number of threads / processes in the system, we have a large overhead for creating a process / thread. But we do not need to care much about working with sockets.
New hype/modern
- at startup, data handlers (our services/applications) are registered in the server
- the server opens a socket and listens to all the sockets it has previously opened, hangs waiting for the data arrival / transmission event on the select / poll / epoll method or similar.
- as soon as the server has received a response, it calls the registered handler and transfers a portion of the received data there, receives this data back and sends it to the network to the desired connection
In this case, the server works in one thread, simply calling the handlers sequentially and giving them data. Fast, very fast, nimble, no overhead. But if a handler tries to perform a blocking operation, all other handlers hang, so the handlers communicate with the server by messages and try not to take up a lot of processor resources. Programming is complex.
You can also combine these two approaches by doing both a thread pool and working in asynchronous mode.
To read here for example - https://en.wikipedia.org/wiki/Epoll

Answer 3

Then the question is, how miraculously does Node avoid this? If possible , please explain how everything happens there

Synchronously: we received the request, we are processing it: we consider something there, do we need info from the database / file? - We are waiting, while we are waiting, everything is hanging like a dead weight, we get , we consider something else, we issue the result, we accept the next request.
Asynchronously: we received a request, we process it: we consider something there, do we need info from the database / file? - Don't wait, move on to the next request. As soon as the necessary info has arrived, we return to the failed request, count the uncounted, issue the result, and proceed to the next request.
User. Web servers serve requests from users. When you try to view, for example, this page, your browser sends a request to the web server

HOST: toster.ru
GET: /q/500685

Receives a response containing html, parses html, finds out what else it needs to request: css styles, js scripts, images, and similarly requests them. Etc...
Both true and false at the same time. The truth is that Node really does work that way. The lie is that nothing prevents Java / C / C # / Go / Python / even, with a strong desire, to write an application in php that will process user requests in the same way.

Answer 4

nodeJs does not require a separate web server as it has its own built-in one.

Answer 5

Firstly, it does not process requests from Node with Java, but from the server.

No.
No.
No. You have absolutely no idea what you are writing about.