So, you are wondering “what is Node.js” and how it works. Let’s take a look at our newest article to find out.
What is Node.js?
These are the services that power client applications such as a web app (running inside a browser) or a mobile app (running on a mobile device). These client apps are simply what the user sees and interacts with. They are just the surface. They need to talk to some services in the server or in the cloud to store data, send emails, push notifications.
Node is ideal for building highly scalable, data-intensive and real-time backend services. But using why Node even if there are so many tools and frameworks out there? What is so special about node?
Here are some of the reasons:
- Great for prototyping and agile development
- Superfast and highly scalable
- Large ecosystem of open source libraries available. It is very likely that there is some free and open-source Node js library out there that could be used in many features of the app that you’re building
For example, Microsoft Edge uses Chakra, Firefox uses SpiderMonkey, Chrome uses V8.
But these objects are different from the environment objects in the browser. For example, we don’t have the ‘document’ object but instead, we have other objects that give us more interesting capability like ‘fs’ object for working with filesystem or ‘HTTP’ object for listening for request in a given port.
How Node works
Node apps are highly scalable because of the non-blocking (asynchronous) nature of Node. But what does that mean?
Imagine you’re going to a restaurant. A waiter comes to your table, takes your order and gives it to the kitchen, then he moves on to serve another table while the chef is preparing your meal. So the same person can serve many different tables. He doesn’t have to wait for the chef to cook one meal before serving other customers. This is what we call non-blocking or asynchronous architecture. This is how a Node app works.
The waiter is like a Thread allocated to handle a request. A single thread is used for handling multiple requests.
In contrast to non-blocking (or asynchronous) architecture, we have blocking (or synchronous) architecture.
Let’s see how that works. Back to our restaurant example, imagine you go to another restaurant and a waiter is allocated to you. After receiving your order, he gives it to the kitchen and now he’s sitting in the kitchen waiting for the chef to prepare your meal without doing anything else. He will not take any other order from any table until your meal is ready.
This is what we call blocking or synchronous architecture. And that’s how an application built with frameworks like ASP.NET or Rails work out of the box.
Let’s take a look at a technical example: When we receive a request on the server, a thread is allocated to handle that request. As part of handling that request, it’s likely that we’re going to query the database, sometimes it might take a while till the result is ready. When the database is executing the query, that thread is waiting there, and it can’t be used to serve another client. We have to use another thread for that.
Imagine what would happen if we have a large number of concurrent clients? At some point, we will run out of threads to serve them. All of our threads are busy. As a result, new clients have to wait until free threads are available. Or if we don’t want them to wait, we need to add more hardware. We’re not utilizing our resources efficiently. This is the problem with blocking (or synchronous) architecture. That’s how applications built with frameworks like ASP.NET, Rails work by default. We could make them asynchronous but we have to do extra work.
Node applications are asynchronous by default so we don’t have to do extra things. In Node, we have a single thread for handling all requests. If we need to query a database, the thread doesn’t have to wait for the database to return the data. While waiting, that thread could be used to serve another client.
When the database prepares the result, it puts a message in 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 start processing. This kind of architecture makes Node ideal for building applications that include lots of disks or network access. We could serve more clients without the need of throwing away more hardware. And that’s why Node apps are highly scalable.
In contrast, Node should not be used for CPU-intensive applications like Video encoding or Image manipulation service. Those apps have a lot of calculations done by CPU and few operations that touch the file system or the network. Since Node apps are single-threaded, when performing the calculation to serve one client, others have to wait. That’s why Node should not be used for CPU intensive apps and only be used for building Data-intensive and real-time applications.
We hope this article has answered your question “what is Node.js
Some other articles you might like: