The Node.js Paradox: Doing Everything at Once with Only One Thread

Coming from stuff like Java or C#, where you need a bunch of threads to deal with users all at the same time, Node.js setup just seems off. I mean, in those languages, its one thread per request or you get stuck.

That is the thing that gets me. Node.js says it handles like thousands of connections without multiple threads, just the one. It feels kind of weird at first, right, how a single thread does better than all those multi threaded setups.

Maybe I am not explaining it great, but basically there are these parts that make it work, the event loop for one, then libuv and the thread pool. They handle the heavy stuff without blocking everything.

I think the event loop is what keeps things moving along, non blocking style. The others help with the bits that might slow it down. Sort of like juggling without dropping balls, even if its just one hand.

1. The Core Philosophy: Don't Wait

In regular multi threaded setups, threads just hang around when they need something from the database. Like, they block and do absolutely nothing while waiting for that response to come back. It feels kind of wasteful, I guess.

Node.js does things way differently though. It uses this non blocking I O thing, so instead of sitting idle, it fires off the request and moves on. Sort of like telling the database, here you go with what I need, just ping me when its ready. Then it can jump to handling another task right away, maybe the next request in queue. That part stands out because it keeps everything moving without all that downtime. Traditional ways seem slower by comparison, at least from what I remember reading.

2. The Engine Room: Libuv and the Event Loop

Though your JavaScript code executes in a single-threaded application, in fact, Node.js as an environment operates within multiple threads through the use of libuv, a C++ library for managing asynchronous input/output to and from files.

How it Works:

V8: Runs your JavaScript code; when it encounters an async operation (for example - fs.readFile), it’ll pass that task off to Libuv immediately without waiting for the task to complete before continuing with execution.
Libuv: The library that will determine whether or not the task can be run by the O/S’s kernel directly or needs to be executed via the Thread Pool.
Event Loop: The Event Loop is a continuous loop that will keep checking to see if various tasks have done their job until they have finished. When Libuv indicates to Event Loop that it has finished reading that file, the Event Loop will pass this information down to your original JavaScript code base (e.g., callback or event).

3. The Secret Weapon: The Thread Pool

Wait, I thought Node.js operates with one main thread?

Node.js uses only one thread when dealing with the event loop. However, libuv maintains a thread pool, which is where expensive I/O operations get queued and executed by worker threads. Typically, the default size is four (4) threads.

When you perform an expensive operation such as password hashing with bcrypt or reading a large file from disk, libuv is able to move that work from the Event Loop (the single-threaded portion) to one of the threads in the libuv thread pool.

When the work is complete on the worker thread, that thread will return the results back to the Event Loop.

The key point to take away is that while the Main Thread performs the logic of your application, it is the libuv Thread Pool that does the actual work involved with I/O in your application.

4. Seeing it in Code

const fs = require('fs');

console.log("1. I am first!");

// This task is handed to Libuv and the Thread Pool
fs.readFile('data.txt', 'utf8', (err, data) => {
    if (err) throw err;
    console.log("2. The file is finally read!");
});

console.log("3. I am third, but I'll probably finish second!");

/** * ACTUAL OUTPUT:
 * 1. I am first!
 * 3. I am third, but I'll probably finish second!
 * 2. The file is finally read!
 */

5. The CPU Brick Wall

Whenever you’re working with a large amount of data processing, Worker Threads are your best option to do the processing without causing your application to lock-up.

On the other hand, where Libuv handles I/O (like interacting with your database) behind-the-scenes, Worker Threads provide a way to run actual JavaScript code concurrently and on a separate core.

1. Why do we need them?

When you have a standard node application and you run a function that takes a long time (10 seconds, for example) to calculate, that blocks the Event Loop. Nothing will connect to your server for 10 seconds because the Event Loop is blocked.

Worker Threads solve this by spawning a new instance of the V8 engine with its own Event Loop which is not a part of the Main Thread.

2. Key Components

You’ll be able to utilize Worker Threads by utilizing the worker_threads module and defining a couple of key components in your code:

Main Thread: is the thread where your server begins execution from and creates Worker Threads.
Worker: a thread of execution that runs a separate script from the main thread.
Message Port: the way you communicate between the Main Thread and Worker (via postMessage and .on('message')).

3. How to Implement

To give you an example of how you can implement Worker Threads to get a heavy loop off of your main thread — I’ve created a sample of what your code would look like to demonstrate this in your article, written in Proper Writer format, shown below:

File: app.js (Main Thread)

// Using Worker Threads for heavy CPU tasks
const { Worker, isMainThread, parentPort } = require('worker_threads');

if (isMainThread) {
  const worker = new Worker(__filename); 
  worker.on('message', (msg) => console.log(`Math Result: ${msg}`));
  console.log("Main thread remains fast and responsive!");
} else {
  // This runs on a separate thread!
  let result = 0;
  for (let i = 0; i < 1e9; i++) { result += i; } 
  parentPort.postMessage(result);
}

6. Worker Threads

If you are doing any form of heavy processing of data, and need to avoid freezing your application whilst doing this, you can use Worker Threads.

Libuv will handle the I/O of things such as possible interactions with your database in the background, whereas Worker Threads will create separate CPU cores with their own instances of JavaScript processing.

1. Why do we need Worker Threads?

In a typical node app, if you executed a calculation that took 10 seconds, the Event Loop would be blocked for the duration of the 10 seconds and no one else would be able to connect to your server.

To solve this problem, Worker Threads will create a new instance of the V8 engine and Event Loop which are separate from the main thread.

2. Components of Worker Threads

You will access Worker Threads using the worker_threads module. There are three key concepts:

Main thread - where your server runs. It creates workers. Worker - a separate thread running an entirely different script. Message port - how the main thread and worker communicate with one another (with postMessage and .on('message')).

3. Practical Implementation

The following example is a code example from the "Proper Writer" perspective to show you how to take a lengthy loop off the main thread.

Filename: app.js (The Main Thread)

const { Worker } = require('worker_threads');

function startBigTask(data) {
    return new Promise((resolve, reject) => {
        // 1. Create a new worker from a separate file
        const worker = new Worker('./processor.js', { workerData: data });

        // 2. Listen for the result
        worker.on('message', resolve);
        worker.on('error', reject);

        worker.on('exit', (code) => {
            if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`));
        });
    });
}

console.log("Main Thread: I am starting a heavy task, but I won't freeze!");
startBigTask(1000000).then(result => console.log("Main Thread: Task finished!", result));
console.log("Main Thread: See? I can still log this immediately!");

Filename: processor.js (The Worker Thread)

const { parentPort, workerData } = require('worker_threads');

// This code runs in parallel to the main thread
let finalValue = 0;
for (let i = 0; i < workerData; i++) {
    finalValue += i; 
}

// Send the result back to the main thread
parentPort.postMessage(finalValue);

7.Conclusion: The Right Tool to Use

The modern web is made for Node.js because we tend to spend more of our time waiting for database responses and API calls (I/O binding) for data than actually performing complex mathematical functions (CPU binding).

In order to minimize memory usage, Node.js only uses a single thread for logical processes and uses a thread pool to offload heavy I/O processing to a separate background queue. Because of this, Node.js is extremely lightweight and provides excellent scalability for your application.

Key Points to Remember:

Event Loop: The single-threaded manager.
Libuv: The C++ engine that executes asynchronous tasks.
Thread Pool: A set of thread handlers used by libuv for high-volume I/O processing.
Worker Threads: Your backup plan for heavy-duty CPU processing.

Command Palette