Explaining how node.js is going to work.
You know that Node.Js applications are highly scalable and this is because of the non-blocking or asynchronous nature of node.
What is Non-blocking or asynchronous architecture?
What do you mean by asynchronous? let me give you a metaphor imagine.
You go to a restaurant, the 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.
What is blocking or synchronous architecture?
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 the 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, a waiter is allocated to you.
They take your order and give 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 they’re just waiting, they’re 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 built with frameworks like a speed net or rails work out of the box.
So when we receive a request on the server, a thread is allocated to handle that request as part of handling that requests.
It is likely that we’re going to query a database and as you know sometimes it may take a little while until the result is ready.
When the database is executing the query that the thread is sitting there waiting, it can’t be used to serve another client.
So we need a new thread to serve another client. imagine what would happen if we have a large number of concurrent clients at some point we’re going to run out of threads to serve these clients.
In that situation, new clients have to wait until three threads are available or if we don’t want them to wait, we need to add more hardware.
Is it possible to use asynchronous architecture?
So with this kind of the architecture, we are not utilizing our resources efficiently. This is the problem with blocking or synchronous architecture.
And as I explained that’s how applications built with frameworks like asp.net worked by default. Of course in asp.net, it is possible to use asynchronous architecture.
But you will have to do extra work for now in contrast no the applications are asynchronous by default. So you don’t have to do anything extra in the node.
We have a single thread to handle all requests, the linear request arrives that a single thread is used to handle that request.
If you need to query a database our thread doesn’t 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 client when the database prepares the result, it puts a message in what we call an event queue.
Node is continuously monitoring this queue in the background. When it finds an event in this queue it will take it out and process it.
This kind of architecture makes node ideal for building applications that include a lot of disks or network access.
We can serve more clients without the need to throw in more hardware and that’s why no applications are highly scalable in contrast.
Node should not be used for CPU intensive applications like a 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 system or the network.
Since no the 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 or CPU intensive applications.
It should only be used for building data-intensive and real-time applications.
Our other articles you should read: