How Node.js Works?
In the previous article we have discussed that Node applications are highly scalable and data intensive and real time applications. This is because of the non-blocking or asynchronous nature of Node. So What do you mean by asynchronous?
Let me give you a metaphor. Imagine you go to a restaurant, a waiter comes to your table, takes your order and gives it to the kitchen. Then they move on to serve another table while the chef is preparing your meal. So the same person can serve many different tables. They don’t have to wait for the chef to cook one meal before they serve another table. This is what we call non-blocking or asynchronous architecture and this is how Node applications work.
The waiter is like a thread allocated to handle a request, so a single thread is used to handle multiple requests. In contrast to non-blocking or asynchronous architecture we have blocking or synchronous architecture.
Let’s see how that works?
So back to our restaurant example, imagine you go to another restaurant and in this restaurant the waiter is allocated to you. It takes your order and gives it to the kitchen. Now they are sitting in the kitchen waiting for the chef to prepare your meal. At this time they are not doing anything else, just waiting.
They are not going to take an order from another table until your meal is ready. This is what we call blocking or synchronous architecture. And that’s how applications filled with frameworks like ASP.NET works out of the box. So when we receive a request from another server, a thread is allocated to handle that request. As a part of handling that request, it is likely that we are going to query a database and as you know sometimes it may take a little while until the result is prepared.
When the database is executing the query that thread is sitting there waiting and it cannot be used to serve another client. So we need another thread to serve that client. So imagine what would happen if we have a large number of concurrent clients at some point, we are going to run out of threads to serve these clients. So new clients have to wait until free threads are available or if we don’t want them to wait then we need to add more hardware.
So with this kind of architecture you are not utilizing your resources efficiently. This is the problem with blocking or synchronous architecture and as explained that’s how applications filled with frameworks like ASP.NET works by default.
Off course, in ASP.NET it is possible to use asynchronous architecture or you will have to do extra work for that.
In contrast, Node applications are asynchronous by default. So you don’t have to deal with anything extra.
In Node, we have a single thread that handles all the requests. When a request arrives that single thread will handle that request. If it required to query a database our thread does not have to wait for the database to return the data. While the database is executing our query; that thread will be used to serve another request from another client.
When the database prepares the result it puts a message in what we call an Event Queue.
Node is continuously monitoring this event queue in the background. When it finds an event in this queue, it will take out it and processes it. This kind of architecture makes this node ideal for Input output-intensive applications. For building applications that include a lot of disk or network access, we can serve more clients without the need to throw in more hardware and that’s why node applications are highly scalable.
In contrast, node applications should not be used for CPU-intensive applications like video encoding or an image manipulation service.
In this kind of applications we have a lot of calculations that should be done by CPU and few operations that touch the file systems or the network. Since Node applications are single threaded when performing the calculations to serve one client other clients have to wait and that’s why node should not be used for CPU intensive applications and real time applications.
Visit: Hostripples
