2) Node.js Application: So now that, we have learned about the Node.js architecture, it’s time to learn how a Node.js application runs and this part includes the concept of Node.js being single-threaded and its non-blocking nature as well. So, first of all, what is a thread? A thread in simple terms is basically a set of programming instructions that can be run independently in a computer’s processor and every process that we want to run as its own thread to run the programming instructions and the process can have more than one thread. But, the point to remember is, Node.js application runs only on a single thread and by that, It means whether that Node.js application is being used by 5 users or 5 million users, it will only run on a single thread which makes the Node.js application blockable (which means that a single line of code can block the whole app because an only single thread is being used). So, to keep the Node.js application running, asynchronous code must be used everywhere having callback functions because as we know that asynchronous code keeps on running in the background, and the callback gets executed as soon as the promise gets resolved rather than synchronous code which blocks the whole application until it gets finished executing. But, we can still use synchronous code however at someplace in our application and that place is before our application enters Event-loop. Event-loop is what allows Node.js applications to run non-blocking asynchronous I/O based operations i.e, all the asynchronous code is managed and executed within the event-loop and before that, we can use our synchronous code which is in this case known as Top-Level code. So, try to write synchronous code only for those operations which are executed only once at the start of our application and not every time, for Ex: reading some data from your computer memory which later can be requested by some user (many times) in asynchronous code.
So, as you can see whenever the Node.js application starts in a thread, the first step is to initialize the application and execute the top-level code which as we have said earlier is the only synchronous code that we should have in our application. The next step is to require the modules that we specified in our code (which is normally written at the very top).
The very next step is to register all the event callbacks which are in our code which will then be sent to the event loop for execution where most of our code in the node app is executed. But sometimes, some tasks are too heavy to be executed in our event-loop by a single thread so those tasks are sent to the thread-pool (provided by Libuv) are the 4 extra threads to execute heavier tasks without blocking the main thread. The number of threads can be increased and the user did not have to specify the tasks which have to be off-loaded because the event-loop does it all by itself but we can specify the number of threads.
3) The Event-loop: So, you need to remember this point that event-loop is the place where all our asynchronous code is executed. For a moment, why don’t you in the first paragraph and read that again because we will be covering the third point of Node.js which is that, it is based on event-driven architecture? The whole idea behind the event-loop is that it works on this architecture or these three steps as shown below:
- Events are emitted, These events can emit from an asynchronous function like getting an HTTP request, fileSystem module finished reading the file or a timer has been finished. These events can vary on our code.
- After that, Event-loop picks them up.
- Callback functions are executed (based on your code).
Other than this, event-loop offloads heavier tasks to the thread-pool.
Note: Event-loop does follow a sequence to run the callbacks.
Typically, an event-loop has 4 phases and for each phase, it sets a callback queue that contains callback functions from the emitted event.
- The first phase is the Expired timeout callbacks, which are the callback functions from setTimeout() function etc.
- The second phase is the callbacks from I/O polling like an event of reading a file or any HTTP request.
- The third phase is the callbacks from the setImmediate() function, which are the callback functions that the user wants to execute just after the I/O polling. These types of functions can be specific for some only certain cases.
- And the last is, Close callbacks which are emitted from events like the closing of the webserver, etc.
Note: All the callbacks available from the certain phase are first executed and only then it goes to the next phase. Also, at the end of the event loop, it checks whether any other event is still going on and if it is then it returns back to the first phase and so on otherwise the program exits from the event loop.