Deep diving into NodeJS(Part1):

Part1:is node really single-threaded?

If you’re a javascript developer or backend developer you must have come across a term about node that is single-threaded or its highly robust nature and fast execution which made nodejs one of the top choices to include in tech stack from startups to big corporations.

But have you ever wondered how can something run on a single thread but is doing a better job than other frameworks which are multithreaded in nature, If you are also curious about this, I’ve written this that explains what’s happening behind the scenes?

Let’s start,

Process workflow

When you send a JS-based request that can require a range of actions from reading, writing, or mutating data which can be only done at the OS level, to achieve this node uses a V8 engine, the same engine that Chrome uses to interpret JS in the browser itself, the same engine is used by a node in the backend to convert your JS code into machine code so it carries further operations, summarizing visually.

But there’s one issue with only using V8, you see V8 was meant to use with the browser it was not built to create backend operation, that’s why NodeJS uses Libuv along with V8 to add needful functionalities for server-specific operations, like IO operation, in fact, Libuv is one of the main reason behind robust event handling

Libuv is responsible for NodeJS to work as a runtime during JS code execution, it handles the processes which are specifically not viable to implement on the v8 side

But still, our question that remains unanswered was how nodeJS is in spite of using a single thread is so robust & quicker, let’s deep dive into libuv for that

Libuv?

Imagine we have this multi-threaded server (running Ruby on rails) that reads a file saved on the server and sends it to the requesting browser. It’s important to understand that Ruby won’t read the file for us directly. Ruby will tell the file system to read the file and return the contents. The file system is a program used to store and retrieve data on a computer.

The point is, Ruby just sits there doing nothing till the file system is done. And then Ruby collects the content and sends the contents to the browser. Here’s where NodeJs comes in. In Node, while the file system is reading the file, Node uses idle time to handle other requests. When the file system is done, it’s smart enough to tell Node to come to take the resource and send it to the browser. This is possible because of Node’s event loop

The event loop is basically a program that waits for events and dispatches them when they happen. One other important fact you might know is that JavaScript is a single thread and so is Node.

Unlike other languages that require a new thread or process for every single request, NodeJs takes all requests and then delegates most of the work to other system workers. This is where the Libuv roles come to play it handles this work effectively with help from the OS kernel.?Libuv has a set of thread pools that nodejs leverages which is the single-threaded itself. Think of the relation between nodeJS and libuv like a higher-level manager and a lower-level manager which handles workers internally so the upper-level manager cannot get disturbed and do its work properly. When the background workers are done doing their work, they emit events to NodeJs callbacks registered on that respective event.

So what NodeJs developers basically do is write event handlers that get called when certain Node events happen. This is how NodeJs are extremely faster than multi-threaded systems. Yeah even with a single thread.

This is because programs usually don’t only consist of numeric, arithmetic, and logic computations that take much time. In fact, a lot of times they merely write something to the file system, do network requests, or access peripheries such as the console or an external device. Node excels in situations like this. When it experiences them, it quickly delegates the work to someone else and tackles other incoming requests.

But things can’t be all good, because you know

NodeJS in its pure form handles blocking tasks such as disk operation or networks operations with ease but if the request is non-blocking such as CPU intensive task or operation related to RAM not so fast since the task does not get handled in libuv it gets handled in a single thread, so its stops rest of operations because the main thread is busy,

So in the next part of this blog, we will see how we can tackle this limitation,& also learn to handle concurrency, streams,&sync async event handling workflow of node, etc