Search for a command to run...
Node.js is single-threaded, yet it can handle thousands of concurrent users. Here is how callbacks and Promises make its non-blocking architecture possible.
No comments yet. Be the first to comment.
These are the assignments or knowledge dumps I decide to write for the "Chai aur Code's web Dev Cohort 2026"
For 15 years, JavaScript was trapped in the browser. Then someone ripped out its engine, gave it server access, and changed web development forever.
RAG helps LLMs answer questions using your own data, but it doesn't guarantee correct answers. Here's how the pipeline works and where it commonly breaks down.
Imagine asking an AI, "Write a blog," versus "Act as an SEO expert and write a 1,000-word blog on AI safety formatted in markdown." The difference in the resulting output is night and day. A prompt is
Spotify and Apple Music make it incredibly easy to showcase your live listening habits on your website. YouTube Music? Not so much. After doing some setup you can do an API call and fetch your account
Arthur C. Clarke's famous third law: "Any sufficiently advanced technology is indistinguishable from magic" perfectly captures how the pace of human innovation works. From carrying supercomputers in o
Why HTTP is amnesiac, the difference between transport and state, and how to choose the right auth strategy for your Node.js app.
If you block the main thread in a browser, you annoy one user. The tab freezes, they get frustrated, and maybe they refresh.
If you block the main thread in Node.js, you take down the entire server. Every user waiting for a response gets frozen.
Node.js is single-threaded. It processes your JavaScript code using a single event loop. But it is also heavily used for building APIs and web servers, which spend the vast majority of their time waiting on external systems: reading files from a hard drive, querying a database, or making network requests to other servers.
If Node.js handled these Input/Output (I/O) operations synchronously, it would be useless as a web server. To survive, Node.js offloads I/O tasks to the operating system and continues executing the rest of your code.
But how does it know when the OS is finished? It needs a mechanism to receive the data once it's ready. Historically, that mechanism was the callback. Today, it is the Promise. Let's look at how both approaches handle the exact same problem.
Let’s start with a classic server task: reading a file from the disk.
When Node.js was created, the core API was built entirely around callbacks. The convention was strict: pass a function as the last argument to an asynchronous method. When the task completes, execute that function. The first parameter of the callback is always reserved for an error object, and the second for the successful data.
Here is what that looks like using Node’s fs (File System) module:
const fs = require('fs');
console.log("1. Requesting file...");
// Asynchronous file read
fs.readFile('user.json', 'utf8', (error, data) => {
// This is the callback function
if (error) {
console.error("Task failed:", error.message);
return;
}
console.log("3. File data received:", data);
});
console.log("2. Doing other server work...");
Step-by-step Execution Flow:
Node logs "1. Requesting file...".
Node hits fs.readFile. It delegates the actual disk reading to the underlying C++ libraries (libuv) and the operating system.
Node does not wait. It immediately moves to the next line and logs "2. Doing other server work...". This is non-blocking I/O in action. The server is now free to handle other users' HTTP requests.
Milliseconds later, the disk finishes reading. Node pushes our callback function onto the event queue, and executes it, logging "3. File data received".
Callbacks work perfectly for a single operation. But server logic is rarely that simple.
Imagine a workflow where operations depend on one another. We need to:
Read config.json to get the name of a target file.
Read that target file to get some user data.
Write that user data to a backup.txt file.
Using standard callbacks, the code shapes itself into a wedge:
// The Nested Callback Execution Chain
fs.readFile('config.json', 'utf8', (err, configData) => {
if (err) return console.error("Failed to read config:", err);
const targetFile = JSON.parse(configData).fileName;
fs.readFile(targetFile, 'utf8', (err, userData) => {
if (err) return console.error("Failed to read user data:", err);
fs.writeFile('backup.txt', userData, (err) => {
if (err) return console.error("Failed to write backup:", err);
console.log("Backup completed successfully!");
});
});
});
This is the infamous Callback Hell. The problem isn't just the messy indentation. The real problem is maintainability. Notice how we have to write if (err) three separate times? Error handling is tightly coupled to every single step. If you want to refactor this to add a database lookup in the middle, you have to carefully pry apart the nesting, hoping you don't break the scope of variables like targetFile.
To fix this architectural flaw, Node.js adopted Promises.
A Promise is an object that represents the eventual completion (or failure) of an asynchronous operation. Instead of passing a callback into the function, the function immediately returns a Promise object. You then attach your success and failure logic to that object.
Today, Node.js provides a built-in Promises version of the file system module. Let's rewrite our backup script using fs.promises.
const fs = require('fs').promises;
fs.readFile('config.json', 'utf8')
.then((configData) => {
const targetFile = JSON.parse(configData).fileName;
// Returning a Promise here chains it to the next .then()
return fs.readFile(targetFile, 'utf8');
})
.then((userData) => {
return fs.writeFile('backup.txt', userData);
})
.then(() => {
console.log("Backup completed successfully!");
})
.catch((error) => {
// A single catch handles errors from ANY of the steps above
console.error("Operation failed:", error);
});
If you compare the two snippets above, the benefits of Promises in a Node.js environment become immediately obvious:
1. Flattened Architecture The code grows vertically instead of horizontally. By returning a new Promise inside a .then() block, you chain operations together. Task A finishes, and hands its result down to Task B, which hands it to Task C.
2. Centralized Error Handling In the callback version, an error at step 3 meant step 1 and 2 had already polluted the code with error checks. In the Promise version, if any file read or write fails, the execution immediately jumps out of the .then() chain and falls straight into the single .catch() block.
Diagram: Promise Lifecycle Flow
[ Pending ]
│
├── fs.readFile('config.json') ──(Success)──> [ Fulfilled ]
│ ↓
├── fs.readFile(targetFile) ──(Success)──> [ Fulfilled ]
│ ↓
├── fs.writeFile('backup.txt') ──(Success)──> [ Fulfilled ]
│
└── (If ANY step fails) ────────────────────> [ Rejected ] -> .catch()
Node.js forces you to think asynchronously. You are building a system that serves many masters at once, and you cannot afford to wait.
Callbacks laid the groundwork for this non-blocking architecture, proving that a single-threaded server could rival massively multi-threaded servers in performance. But Promises gave us the ergonomics we needed to build complex, reliable data pipelines.
If you are writing Node.js today, leave standard callbacks in the past. Use Promises (or their modern syntactic wrapper, async/await), centralize your error handling, and keep your event loop running fast.