Understanding node.js

JavaScript’s rising popularity has brought with it a lot of changes, and the face of web development today is dramatically different. The things that we can do on the web nowadays with JavaScript running on the server, as well as in the browser, were hard to imagine just several years ago or encapsulated within sandboxed environments like Flash or Java Applets.
Before digging into Node.js, you might want to read up on the benefits of using JavaScript across the stack which unifies the language and data format (JSON), allowing you to optimally reuse developer resources. As this is more a benefit of JavaScript than Node.js specifically, we won’t discuss it much here. But it’s a key advantage to incorporating Node in your stack.
Thats enough of introduction lets dive into Node .
What is Node.js:
“Node.js is a JavaScript run time built on Chrome’s V8 Engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js’ package ecosystem, npm , is the largest ecosystem of open source libraries in the world.”
“Node.js is a server-side platform wrapped around the JavaScript language for building scalable, event-driven applications .”
Yes you heard it right it’s server-side JavaScript. This is confusing for even experienced programmers because the traditional JavaScript environment has always been client-side in a user’s browser or in an application that is talking to a server. JavaScript has not been considered when it comes to the server responding to client requests, but that is exactly what Node.js provides.
But were the terms Non-Blocking I/O, Single Threaded, Event-Loop bit heavy on you? Do not worry they are pretty simple lets break it down.

We will dig into what non-blocking I/O means and how Exactly Node’s Single Thread Model works :
In order to understand non-blocking I/O, let’s picture a common scenario. Suppose you are at a restaurant with friends.
A typical experience at a restaurant would be something like this:
1. You sit at a table and the server grabs your drink order.
2. The server goes back to the bar and passes your order to a bartender.
3. While the bartender is working on your drink, the server moves on to grab another tables drink order.
4. The server goes back to the bar and passes along the other table’s order.
5. Before the server brings back your drinks, you order some food.
6. Server passes your food order to the kitchen.
7. Your drinks are ready now, so the server picks them up and brings them back to your table.
8. The other table’s drinks are ready, so the server picks them up and takes them to the other table.
9. Finally your food is ready, so server picks it up and brings it back to your table.
Basically every interaction with the server follows the same pattern. First, you order something. Then, the server goes on to process your order and return it to you when it’s ready.
Once the order is handed off to the bar or kitchen, the server is free to get new orders or to deliver previous orders that are completed. Notice that at no point in time is the server doing more than one thing and instead of blocking until your drinks/food is ready it goes on to serve other customers.This is how non-blocking Single Threaded Node.js applications work.

Now that we know what is non-blocking Code , let’s take a look at the missing piece of the puzzle. How does the server knows your food/drinks are ready? Don’t worry that’s pretty simple. When your food is ready and complete they emit an event (Suppose there is a ready event that is emitted when an order is ready ). When ever there is an event corresponding to a order, the server comes back ,picks the food and brings them back to your table (Keep in mind Node can perform only one task at time).
This handling of events is abstracted away from the developer, this is all handled by a library called libuv which provides a mechanism called an Event loop.
Below is Comparison of traditional Architecture vs Node.js :

Now Lets Answer the main question here. Is Node really Single Threaded? If not how it’s different from other traditional Multi-Thread Environments?

Answer to this is a simple concept “everything runs in parallel except your code”. Lets accept the fact that Just because we don’t see it, doesn’t mean it’s not there. Node is actually multithreaded . But the main event loop (consider it as a system which handles I/O Events) is single-threaded by nature .
To understand this, imagine your Event-Loop is the king, and Threads is his army of servants.
The day starts by one servant waking up the king and asking him if he needs anything. The king gives the servant a list of tasks and goes back to Sleep. The servant now distributes those tasks among his colleagues and they get to work.
Once a servant finishes a task, he lines up outside the kings quarter to report. The king lets one servant in at a time, and listens to things he reports. Sometimes the king will give the servant more tasks on the way out.
King’s servants carry out all of his tasks in parallel, but only report with one result at a time, so the king can focus. Similarly Most of the i/o operations (network, disk, File read/write ..) is run on separate threads parallelly, But the final results (ex: After a file is read and result is fetched) is executed one at a time.
One of the biggest pluses about Node is the very fact that more often than not all the code the developer writes is running on one thread but you don’t have to deal with a multi-threaded environment because it’s abstracted away.
When to use Node.js:
Node.js really shines when the number of requests to your server is very high in number with less CPU Computations and high I/O Operations. Node.js is best for real-time web applications employing push technology over web sockets. What is so revolutionary about that? Well, after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely.
One might argue that we’ve had this for years in the form of Flash and Java Applets?? but in reality, those were just sand boxed environments using the web as a transport protocol to be delivered to the client. Plus, they were run in isolation and often operated over non-standard ports, which may have required extra permissions and such. With all of its advantages, Node.js now plays a critical role in the technology stack of many high-profile companies who depend on its unique benefits.
Already Companies like Netflix, LinkedIn, Walmart , Uber have already foreseen the power of Node.js and are shifting to Node. Its high time one must try Node.
More blogs coming soon… 🙂


  1. Nice blog keep it up ...waiting for more content

  2. Interesting article! What are your thoughts on the node cluster api?

    1. Hey! primary use case of node cluster API is for networking. It can give a good performance boost and load balancing by spawning multiple processes which uses multiple CPU cores and In case any spawned process dies in an unplanned or planned manner then a new process can be started instantly as a replacement to killed one without any delay or manual interruption.
      But it has dome downsides though Session management is not available, You may want to use redis for central management, working with web sockets is a little catchy and IPC(Inter process communication) is a tedious job to manage application, it is not preferred practice for handling complex applications.
      In coming blogs I will cover using Socket.IO with node cluster API :)


Post a Comment

Popular Posts