- Event loop
- Overall picture
- Blocking vs Non-blocking
With Node.js you can run code on the server side and not only in clients (web browsers mainly).
Let’s focus on the definition but from the to the beginning:
Node.js ^ | | | Code Result | | and | | bindings | v V8
V8 needs bindings in order to return results that are not part of the language, for example, access to the filesystem.
What Node.js do is wrap v8 with custom options, we will see more details in the following sections.
In 2017 V8 introduces Node.js in its testing suite, officially making Node.js a target for the JS engine, in addition to Chrome.
Continuing with the definition:
These can be utility libraries or APIs which allow communicating with the world surrounding the engine. An example here might be access to information about the web browser in which your script is executed, environmental information for Node.js or anything needed to the proper functioning of the software.
Another misconception is think Node.js only uses one thread.
Node.js apps run in a single process, without creating new threads to handle the new incoming requests.
There is a worker threads pool inside the runtime. Those threads are controlled by the event loop.
When programming in node we should try to program in an event driven programming fashion, which is a programming paradigm where the execution is guided by events like incoming requests. This remains me the old days when I did some code in second life.
In Node.js the event loop allows performing non-blocking I/O operations using the system kernel whenever possible.
Most modern kernels are multi-threaded, so with one Node.js thread handles multiple operations executing in the background by using the system kernel.
Blocking vs Non-blocking
Node.js uses an event-driven, non-blocking I/O model.
I/O is the communication between node and the external world, like network (fetch some records from the database or to write them), hard drive (read or write files).
While Node.js is doing I/O, it is not blocked. This model is used because if the browser is fetching something like images, it does not block the page, offering a better experience for the user.
We can see the difference with two simple examples. All the code is here.
This code is blocking:
The result is:
This code is non-blocking
The result is:
The following diagram should help to understand whats going on
Blocking Non Blocking +----------+ Read first file +-+ Start to read first file +----------+ +-+ +-+ Print first result +-+ Start to read second file +-+ +-+ +-+ Print Question +-+ Print Question +-+ +-+ +----------+ Read second file +----------+ Print first result +----------+ +----------+ +-+ Print second result +----------+ Print second user +-+ +----------+
In the blocking scenario what happens is:
- Read first file
- Print the result
- Print question
- Read second file
- Print the result
So until the operations do not finish, it does not continue with the others.
In the non-blocking scenario what happens is:
- Start reading first file
- Start reading second file
- Print question (Because it is not blocked and can continue)
When finished reading the file:
- Print the first result
- Print the second result
By using non-blocking the thread and using properly the event loop, we can reduce the time from 15 ms to 5 milliseconds
https://stackoverflow.com/questions/36766696/which-is-correct-node-js-architecture http://abdelraoof.com/blog/2015/10/28/understanding-nodejs-event-loop/ https://nodejs.org/en/docs/guides/