Let's see how Node js works behind the scenes.
There are a few things that we need to understand before diving deeper about node js.
Node js is a javascript runtime, that helps us to run javascript code on the server-side. It helps us to build largely scalable network applications.
Unlike other models, node is single-threaded. So, whatever request comes to the application, it is handled by just one thread. Being single-threaded, node js is still very much efficient and can handle concurrent requests. Let's look at what is blocking and non-blocking first.
Blocking and non-blocking - Generally, if we talk about other languages if anything comes to a thread, that thread is responsible for executing that complete operation. But, they are multi-threaded. So, every request goes to a new thread depending upon the number of threads.
Now, consider we have 5 threads in the system, and there are 6 requests. So the one request (the 6th one) will have to wait for a thread to get free. So, it is getting blocked because a thread can only be engaged to one operation at a time.
And node is single-thread. So every request has to be handled with that thread only. Node is event-driven and works on 2 concepts -
a. Non-blocking I/O
b. Asynchronous
Non-blocking I/O means that the main thread won't be blocked in any I/O operations and the server can handle concurrent requests.
Asynchronous means the use of callbacks. This is because we don't know the time any task will take. We will look at callbacks in a while.
Node js uses an event loop as it is event-driven, and it is literally the heart of node.
Now, this loop has different phases for different types of operations and functions.
And there is an event queue for registering callbacks associated with the phases.
When a request comes to the server, the single thread is responsible for communicating with the event loop and registering callbacks. Consider getting a request which needs to read a file from OS and another one that goes on another server or database.
Now, the thread first receives a request, a callback is registered and the thread is free for the other request. So instead of performing the actual operations, it queues and registers the callbacks.
Once the operation is completed the callbacks are called and the thread knows that the operation is completed. It sends back the response. It is not blocked by one request.
The question is what is responsible for performing the operations as the event loop is single-threaded?
Node uses a library called libuv. It is built in C and works with the OS and kernel. And this uses multiple threads accordingly and is responsible for performing a task.
So after the execution, be it file read or communicating to other server or database, callback is called!!
This is great for I/O tasks. This is very fast and super awesome when the stuff is asynchronous and not CPU intensive. Consider there is some operation that involves calculations, at this time the main thread is blocked.
But there is one more thing. With the event loop, node also manages a thread pool. And it contains worker threads. They are useful for performing CPU-intensive JavaScript operations. There are by deault 4 of those and that can be changed.
But, this is the major reason why it is not preferred for CPU-intensive operations. If there are requirements where we have a lot of CPU-intensive tasks, where we use complex algorithms we use languages like Java, Python, etc. We need multiple threads in these situations.
Node is very much effective for I/O like reading/writing files, reading/waiting for network data, etc. Node is easy to learn and helps in building highly scalable servers. Scalability is a true jewel of node environment.
Node is one of the most popular things people are learning. And node is used in building a lot of great products and applications. There are a lot of frameworks getting used with Node like Express, Loopback, Fastify, Nest, etc.
That's all for this blog, this was an overview of how it works behind the scenes. But you don't need to worry about this a lot as it is all happening behind the scenes.
Do check this blog if you want to set up a basic node and express server - https://hashnode.chakitarora.com/how-to-start-a-basic-node-and-express-server
You can find it in this thread as well -
Thank you for reading. Let me know if you find it useful.
You can find me on twitter. I am quite active there and keep sharing my journey.
Top comments (2)
Hey thanks for the great article. However i have a query!!
Suppose the internal worker thread pool is 5. If there comes 7 requests, min thread assign tasks to internal thread thereby making main thread free, but when it comes to 6th request, what will happen if none of the internal threads are available?
I am trying to learn the concept. Please feel free to correct me.
When there are 7 requests and the internal worker thread pool is set to 5 threads, here's what would happen:
a. The first 5 requests would be assigned to the 5 worker threads in the thread pool.
b. The 6th request would have to wait in a queue, as there are no available worker threads to handle it.
c. The 7th request would also have to wait in the queue, as all 5 worker threads are already occupied.
Once a worker thread completes its task, it becomes available again and can pick up the next request from the queue. This queue management is handled automatically by the Node.js runtime.
The key point here is that the main event loop remains free to handle other non-blocking I/O operations, such as handling incoming connections, while the worker threads take care of the CPU-intensive tasks.
In the case where all worker threads are busy and a new request comes in, the request will be queued and processed as soon as a worker thread becomes available. This queuing mechanism helps to maintain the responsiveness of the main event loop, even when there is a high volume of CPU-intensive tasks.