Now that we know the story, it becomes easy to understand Node.js for us.

What is the event loop?

In Node.js, the event loop is a part of libuv (libuv is a multi-platform support library with a focus on asynchronous I/O). It was primarily developed for use by Node.js. The event loop allows Node.js to delegate some tasks to another thread available in the thread pool.

Why does Node.js need an event loop?

We all know that JavaScript runs on a main thread (single thread), so if in the main thread we run some task that ultimately blocks the main thread for a long time, a convoy effect may be encountered. Due to the event loop and task delegation, Node.js can execute multiple tasks concurrently.

Event Loop Phases in Node.js

Till now, we understood that the event loop works like a task manager. But internally, the event loop itself is divided into multiple phases. Every phase has its own responsibility and queue.

Mainly, we discuss these important phases:

1. Expired Timers Phase

2. I/O Callbacks Phase

3. Poll Phase

4. Check Phase

There is also a close callbacks phase, but initially, these four are enough to understand the event loop properly.

1. Expired Timers Phase

This phase executes callbacks of expired timers, like:

• setTimeout()

• setInterval()

Many beginners think a timer executes exactly after the given delay, but that is not fully true. The delay means the minimum waiting time.

Let us understand this using an example.

Guess The Output

console.log("Start");

setTimeout(() => {
  console.log("Timer Callback");
}, 0);

console.log("End");

Try guessing the output before reading further.

Output:

Start
End
Timer Callback

Why?

• console.log("Start") executes immediately.

• setTimeout() gets delegated to libuv.

• Its callback waits inside the timer queue.

• console.log("End") executes immediately.

• Once the call stack becomes empty, the event loop pushes the timer callback into the stack.

Even though the delay is 0, It still waits for the current execution to complete.

2. I/O Callbacks Phase

This phase executes callbacks related to completed I/O operations, like:

• File reading

• Database operations

• Network requests

Guess The Output

const fs = require("fs");

console.log("Start");

fs.readFile("demo.txt", () => {
  console.log("File Read Completed");
});

console.log("End");

Output:

Start
End
File Read Completed

Why?

• File reading is an asynchronous I/O task.

• Node.js delegates it outside the JavaScript thread.

• Meanwhile, the main thread continues execution.

• After file reading completes, the callback enters the I/O callback queue.

• The event loop executes it later.

This is why Node.js remains non-blocking.

3. Poll Phase

The poll phase is one of the most important phases in the event loop.

Its responsibilities are:

• Checking for new I/O events

• Executing I/O related callbacks

• Waiting for incoming events if nothing is available

You can think of the poll phase as the heart of the event loop.

Guess The Output

const fs = require("fs");

setTimeout(() => {
  console.log("Timer");
}, 0);

fs.readFile("demo.txt", () => {
  console.log("File Read");
});

Most beginners think the timer executes first.

But output can be:

File Read
Timer

or sometimes:

Timer
File Read

Why?

Because file reading speed depends on the operating system and system performance. The poll phase handles I/O completion timing dynamically.

This is why async execution order sometimes becomes tricky.

4. Check Phase

The check phase executes callbacks scheduled using.

Guess The Output

setTimeout(() => {
  console.log("setTimeout");
}, 0);

setImmediate(() => {
  console.log("setImmediate");
});

Output can vary:

setTimeout
setImmediate

or:

setImmediate
setTimeout

Why?

Both are asynchronous, but they belong to different phases:

• setTimeout() → timers phase.

• setImmediate() → check phase

Execution timing depends on the current state of the event loop.

setImmediate vs setTimeout Inside I/O

Now, let us see a very important interview question.

Guess The Output

const fs = require("fs");

fs.readFile("demo.txt", () => {
  setTimeout(() => {
    console.log("setTimeout");
  }, 0);

  setImmediate(() => {
    console.log("setImmediate");
  });
});

Output:

setImmediate
setTimeout

Why?

Within an I/O cycle:

• After the poll phase completes,

• The event loop directly enters the check phase.

• So it setImmediate() executes before timers.

This is one of the most important practical behaviours of the Node.js event loop.

Simplified Event Loop Flow

The simplified flow looks like this:

Expired Timers
       ↓
I/O Callbacks
       ↓
Poll Phase
       ↓
Check Phase
       ↓
Repeat Again

The event loop continuously rotates through these phases while the application runs.

How This Makes Node.js Scalable

Node.js: Instead of spawning multiple threads for each request,

• Uses a single main JavaScript thread

• Delegates async operations to system/libuv

• Uses the event loop that allows efficient handling of callbacks

And for this reason:

• Memory usage stays lower

• Reduces context switch overhead

• Can process thousands of calls simultaneously

That’s why Node.js is widely used for:

• APIs

• Applications in real-time

• Streaming services

• Chat systems.

• Online servers

Conclusion

The event loop is the heart of Node.js, being non-blocking and scalable. It performs continuous checks on various phases and triggers callbacks when the call stack is available.

Comprehension:

• clocks,

• I/O callbacks,

• polling stage,

• and phase check

helps developers write better async code and avoid confusion about the order of callback execution in Node.js.

What is Blocking Code?

Blocking code stops the execution of other tasks until the current task finishes.

Imagine a restaurant with only one worker. If that worker starts cooking one order, every other customer must wait until the cooking is complete. This is exactly how blocking code works.

Example:

const fs = require("fs");

const data = fs.readFileSync("file.txt", "utf8");

console.log(data);
console.log("Next Task");

Here readFileSync() blocks the execution. Node.js waits until the file is fully read before moving to the next line.

Why Blocking Slows Servers

In backend servers, thousands of users may send requests at the same time.

If one request blocks the server while reading a file or fetching database data, other users must wait. This reduces performance and scalability.

Request 1 ---> Reading File ---------> Done
Request 2 ---> Waiting...
Request 3 ---> Waiting...

This becomes a huge problem in high-traffic applications.

What is Non-Blocking Code?

Non-blocking code allows Node.js to continue executing other tasks while a slow operation runs in the background.

Example:

const fs = require("fs");

fs.readFile("file.txt", "utf8", (err, data) => {
  console.log(data);
});

console.log("Next Task");

Here, Node.js starts reading the file but does not wait for completion. It immediately moves to the next task.

Async Operations in Node.js

Most operations in Node.js are asynchronous by default:

• File reading

• Database queries

• API requests

• Network operations

These tasks are handled using callbacks, promises, or async/await.

Non-Blocking Execution Flow

Request 1 ---> Reading File ----\
                                 ---> Continues Other Tasks
Request 2 ---> Processing ------/
Request 3 ---> API Call --------/

This is why Node.js performs extremely well for APIs, chat apps, streaming platforms, and real-time systems.

Instead of waiting, Node.js keeps working. That single idea is what made Node.js revolutionary.

Ryan Dahl took the powerful V8 JavaScript engine from Google Chrome and combined it with an event-driven architecture and low-level system capabilities. This enabled JavaScript to be executed outside of the browser for the first time in a practical and scalable manner. Node.js rapidly became one of the most important technologies in modern web development.

What is Node.js?

Node.js is a JavaScript runtime that allows developers to run JavaScript code on the server side.

One of the most widely held misconceptions about Node.js is that it is a programming language. It isn't. JavaScript is the language. Node.js is the runtime that lets you run JavaScript outside the browser.

Before Node.js, JavaScript could only run in browsers (which had built-in JavaScript engines). Node.js broke this by putting the V8 engine into a stand-alone runtime.

In simple words:

• JavaScript = the language

• V8 = the engine that understands JavaScript

• Node.js = the environment that allows us to run JavaScript outside of the browser.

Why JavaScript Was Originally Browser-Only

JavaScript was invented in 1995 to make websites interactive. Browsers such as Chrome, Firefox, and Safari incorporated JavaScript engines to parse and execute JavaScript code.

The browser had features like the following:

• DOM manipulation

• Handling events

• Timer’s

• Browser API

This dependence on browser APIs meant that JavaScript could not directly access operating systems, files, or network sockets like backend languages could.

At that time, backend development was dominated by technologies such as the following:

• PHP

• JavaScript

• ASP.NET

• Ruby,

While JavaScript was stuck on the frontend, these languages handled databases, authentication, APIs, and server-side logic.

How Node.js Made JavaScript Run on the Server

Ryan Dahl understood that the asynchronous nature of JavaScript was perfect for performing lots of operations concurrently.

He used Chrome’s V8 engine and hooked it into C and C++ system-level libraries. This combination made Node.js.

The V8 engine compiles JavaScript straight into machine code, so it is very fast to run.

Node.js also brought with it an event loop and a non-blocking I/O model. Node.js can process other requests concurrently instead of waiting for one task to complete before starting another.

This made Node.js highly efficient for applications with large numbers of concurrent users.

Browser JavaScript vs Node.js

+-------------------+        +----------------------+
| Browser JavaScript|        |      Node.js         |
+-------------------+        +----------------------+
| Runs in browser   |        | Runs on server       |
| Accesses DOM      |        | Accesses file system |
| Handles UI events |        | Handles APIs         |
| Frontend logic    |        | Backend logic        |
| Browser APIs      |        | OS and network APIs  |
+-------------------+        +----------------------+

JavaScript in the browser is all about user interfaces. In Node.js, JavaScript is used for server operations, databases, APIs, authentication, etc.

High-Level Overview of the V8 Engine

V8 is Google Chrome’s JavaScript engine developed by Google.

Its main job is to convert JavaScript code into machine code that computers can execute very quickly.

Earlier JavaScript engines interpreted code line by line, which was slower. V8 improved performance using Just-In-Time (JIT) compilation.

You do not need to understand deep engine internals to use Node.js effectively. What matters is that V8 made JavaScript fast enough for server-side applications.

Understanding Event-Driven Architecture

V8 is a JavaScript engine developed by Google for Google Chrome.

Its primary function is to translate JavaScript code into machine code that computers can run extremely quickly.

The old JavaScript engines interpreted the code line by line, which was slower. V8 used Just-In-Time (JIT) compilation for better performance.

You don’t need to know how the engine works internally to be able to use Node.js. What matters is that V8 made JavaScript fast enough for server-side apps.

Understanding Event-Driven Architecture

One of the biggest advantages of Node.js is its event-driven architecture.

Most traditional backend systems create a new thread for each request. This takes a lot of memory and resources from the system.

Node.js works differently.

Node.js primarily runs on a single thread with an event loop rather than spawning lots of threads.

Here is a simplified flow:

Phases of the Event Loop

Phase 1: Timer

Runs callbacks scheduled by ⁣ it. Callbacks are invoked when their delay time is reached.

Phase 2: Pending Callbacks

Handles system-level callbacks that were deferred from previous operations.
This includes some network errors and completed TCP operations.

Phase 3: Idle / Prepare

An internal phase used by Node.js for preparation work.
Developers usually do not interact with this phase directly.

Phase 4: Poll

The most important phase where Node.js waits for and processes I/O events.
Tasks like file reading, database queries, and API responses are handled here.

Phase 5: Check

Executes callbacks scheduled using setImmediate().
This phase runs immediately after the poll phase completes.

Phase 6: Close Callbacks

Handles close events for resources like sockets and streams.
For example, socket.on('close') callbacks execute in this phase.

Node.js vs Traditional Backend Runtimes

PHP

Often in PHP, each request is a new process or thread. This is great for a lot of applications, but can be resource-heavy when you have high traffic.

JavaScript

Java is multi-threaded and very powerful for enterprise systems. But dealing with threads can complicate things.

Node.js

Asynchronous and non-blocking Node.js is. It can handle many concurrent connections with fewer resources.

That’s why developers quickly jumped on Node.js for real-time applications and scalable APIs.

Real-World Use Cases of Node.js

Node.js is widely used in modern development because of its speed and scalability.

Popular use cases include:

• Real-time chat applications

• REST APIs

• Streaming platforms

• Multiplayer games

• Collaboration tools

• Microservices

• Serverless functions

Major companies like Netflix, PayPal, and LinkedIn have used Node.js in production systems.

Why Developers Loved Node.js

Node.js solved multiple problems at once:

• Developers could use one language for the frontend and backend

• Faster development workflow

• Huge open-source ecosystem through npm

• Excellent performance for I/O-heavy applications

• Easier real-time communication handling

Most importantly, Node.js made JavaScript a full-stack technology.

Modern web applications constantly communicate with servers. Whether you are logging into a website, viewing products in an e-commerce app, or updating your profile on social media, APIs are working behind the scenes to transfer data between the client and server.

One of the most common architectural styles used for this communication is the REST API.

REST stands for Representational State Transfer. It is not a programming language or framework. Instead, it is a set of principles used for designing web services that are simple, scalable, and easy to maintain.

A REST API allows clients and servers to communicate using standard HTTP methods.

Think of it like this:

• The client could be a browser, mobile app, or frontend application
• The server stores and manages data
• The API acts as the bridge between them

When the client requests data, the server processes the request and sends back a response, usually in JSON format.

What Are Resources in REST?

In REST architecture, everything is treated as a resource.

A resource is simply a piece of data managed by the server.

Examples:

• Users
• Products
• Orders
• Comments
• Posts

Each resource has its own URL endpoint.

/users
/products
/orders

If you want information about a specific user:

/users/101

Here, 101 represents the ID of a particular user resource.

REST APIs focus on resources instead of actions. This keeps APIs clean and predictable.

Understanding HTTP Methods

REST APIs use HTTP methods to define what action should happen to a resource.

The four most common methods are GET, POST, PUT, and DELETE.

GET Request

GET is used to retrieve data from the server.

Example:

GET /users

This fetches all users.

GET /users/1

This fetches a single user with ID 1.

GET requests should never modify data. They are only for reading information.

POST Request

POST is used to create new resources.

Example:

POST /users

Request body:

{
  "name": "Pallab",
  "email": "pallab@example.com"
}

The server creates a new user and stores it in the database.

POST is mainly used when adding fresh data to the server.

PUT Request

PUT is used to update an existing resource.

Example:

PUT /users/1

Request body:

{
  "name": "Pallab Karmakar",
  "email": "pk@example.com"
}

The server updates the user with ID 1.

PUT usually replaces the entire resource with updated data.

DELETE Request

DELETE removes a resource from the server.

Example:

DELETE /users/1

The server deletes the user with ID 1 from the database.

This completes the CRUD operations in REST APIs.

CRUD means:

Status Codes in REST APIs

Whenever the server responds, it also sends an HTTP status code.

Status codes help the client understand whether the request succeeded or failed.

Common status codes:

Example:

If a user is successfully fetched:

200 OK

If the requested user does not exist:

404 Not Found

Status codes make APIs easier to debug and understand.

Designing RESTful Routes

A well-designed REST API follows consistent naming conventions.

Good route design:

GET /users
POST /users
GET /users/1
PUT /users/1
DELETE /users/1

Bad route design:

/getUsers
/createUser
/deleteUserById

REST APIs should focus on nouns (resources) instead of verbs (actions).

The HTTP method already explains the action being performed.

REST Request-Response Lifecycle

Here is how a REST API request typically works:

1. Client sends an HTTP request
2. The request reaches the server
3. The server processes the request
4. Database operations may happen
5. The server sends back a response with data and status code

Example flow:

Client → GET /users → Server → Database → Response(JSON)

This request-response cycle powers almost every modern web application.

Why REST APIs Are Popular

REST APIs are widely used because they are:

• Simple to understand
• Lightweight
• Scalable
• Platform independent
• Easy to integrate with frontend apps

They work perfectly with modern technologies like React, React Native, Angular, Vue, and mobile applications.

Conclusion

REST APIs are the foundation of communication in modern web development. They allow clients and servers to exchange data efficiently using resources, HTTP methods, and status codes.

Understanding concepts like GET, POST, PUT, DELETE, route structure, and status codes is essential for every web developer. Once you understand REST principles, building scalable backend systems becomes much easier.

Whether you are creating a blog platform, social media app, or e-commerce website, REST APIs remain one of the most important tools in full-stack development.

In web applications, speed is more than just how quickly a request completes. It’s about how well a server will do when hundreds or thousands of users are interacting with it at once.”

To understand why Node.js is perfect for fast web applications, we need to take a look at how it internally handles requests.

What Makes Node.js Fast

The reasons Node.js performs well are fourfold:

• It is powered by the V8 engine, which compiles JavaScript into machine code.

• It is based on a non-blocking I/O model.

• It employs an event-driven architecture.

• It has a single-threaded event loop.

The performance advantage isn’t that you can do one thing very quickly. It’s from being able to manage many things efficiently without waiting time.

Let us be clear.

Blocking vs Non-Blocking Request Handling

To understand performance, we must first compare blocking and non-blocking systems.

Blocking Model (Traditional Example)

Imagine a restaurant with just one waiter.

Customer places an order. The waiter went to the kitchen to wait for the food to be ready. Mind you, the waiter is not serving other customers.

If there are 10 customers, they only need to wait for the last customer to be done.

Programming-wise:

• Waiting for DB from the server.

• The server is waiting for the file read.

• The server listens for network calls.

• The others must wait.

This can cause delays and poor scalability.

Non-Blocking Model (Node.js)

Now imagine the same restaurant, but a different waiter.

Customer places an order. The waiter hands the order to the kitchen. He is soon back, serving other customers. When the food is ready, the kitchen calls the waiter.

This is how Node.js works.

It doesn't wait for long operations.

How do you want to do it?

• It takes off the slow operations.

• It also processes other requests.

• It accepts the results as they come.

This is called non-blocking I/O.

Understanding Non-Blocking I/O

I/O stands for Input/Output operations, such as:

• Database queries

• File reading

• API calls

• Network communication

These operations are slow compared to CPU speed because they depend on external systems.

In a blocking system:

Request → Wait for database → Continue

In Node.js:

Request → Ask database → Handle other requests → Database responds → Finish

The difference is that Node.js does not waste time waiting.

That is why it can handle thousands of concurrent connections efficiently.

Event-Driven Architecture

Node.js is event-driven.

What does that mean?

It responds to events, instead of running in a predetermined step-by-step blocking sequence.

Potential events:

• A request is received

• File finished reading

• A database that returns data

• The timer has ended

Node.js waits for such events and reacts when they are emitted.

How It Works Conceptually

1. A request comes in.

2. Node.js callback registration

3. The slow task is running in the background.

4. Node.js continues to process other events.

5. The callback is run when the background task completes.

This system is driven by the so-called event loop.

The event loop is constantly checking:

• Is the main thread free?

• Are there any tasks remaining?

If yes, it does the next task.

This efficient event processing allows Node.js to remain responsive even under load.

Single-Threaded Model Explained

One common misunderstanding is:

"If Node.js is single-threaded, how can it handle many users?"

To answer that, we must understand concurrency vs parallelism.

Concurrency vs Parallelism (Simple Explanation)

Parallelism means:

• Multiple tasks run at the same exact time using multiple CPU cores.

Concurrency means:

• Multiple tasks make progress over time without blocking each other.

Node.js focuses on concurrency, not parallelism.

It uses one main thread but manages many operations without blocking.

Imagine juggling multiple balls.

You are still one person.
You are not doing things at the same time.
But you are managing multiple things efficiently.

That is concurrency.

Why Single-Threading Can Be an Advantage

Because Node.js is single-threaded:

• No overhead of thread management.

• There are no complicated thread synchronisation problems.

• There are no race conditions when multiple threads access shared memory.

That makes it easier and more predictable.

Node.js doesn’t spawn new threads for each request it gets; it delegates asynchronously.

The operating system does background work, such as:

• Reading files

• Requests (net)

• Database Intercommunication

When those tasks are done, Node.js resumes execution.

Where Node.js Performs Best

Node.js is best for the following apps:

• I/O intensive

• On Air

• High concurrent

• Network Powered

For example:

• RESTful APIs

• Messaging apps

• Streaming services –

• Dashboards in real time

• Online collaboration platforms

• Notification systems

It’s especially powerful when your applications are spending more time waiting on external resources than doing heavy CPU calculations.

Where Node.js Is Not Ideal

For completeness, it’s important to understand that Node.js is not best suited for:

• CPU heavy workloads

• Mathematical calculations heavy

• Large image processing

• Machine learning jobs

Node.js operates on a single thread, so CPU-heavy operations can cause blocking of the event loop, impacting performance.

However, Node.js is highly efficient for web applications that are mostly doing database and network operations.

Conclusion

Node.js is ideal for building fast web apps as it’s non-blocking and event-driven, meaning it can handle a lot of concurrent requests efficiently.

Node.js will move the slow operations out of the way and will keep processing other tasks. It is light weight and scalable and has less complexities and overheads due to the single threaded model.

Node.js offers an efficient and reliable performance model for I/O intensive, real-time and high-concurrency applications, which makes it a popular choice for modern web development teams across the globe.

Think of middleware like checkpoints or stations on an assembly line. Every incoming request passes through one or more middleware functions before returning a response.

Let’s see what middleware is, where it fits into Express and see practical examples for common use cases.

What Is Middleware in Express?

In Express, middleware is just a function that gets the request and response objects (like a route handler), but it can do three main things:

1. Modify or post the request before it gets to the route handler.

2. Before returning a response to the client, read or edit it.

3. Decide if request should continue, hand control to next middleware, or end request/response cycle.

Basic Middleware Signature:

function myMiddleware(req, res, next) {
  // ...logic here
  next(); // Pass control to the next middleware or route
}

Notice the third argument: next. This is a special function provided by Express to move the request along the pipeline.

Where Middleware Sits in the Request Lifecycle

When a request hits your Express app:

1. The request enters Express.

2. It passes through any configured middleware functions in order.

3. Eventually it reaches a route handler (if not ended early by middleware).

4. The response is sent and the cycle ends.

Analogy:
Imagine a package traveling through an assembly line.
Each station (middleware) can check it, add a sticker, reject it, wrap it, or send it to the next station.
Finally, the package is delivered (response sent back).

Types of Middleware in Express

Express supports several types of middleware, each suited for different use cases.

1. Application-Level Middleware

These are functions applied to the whole app.

Example: Logging Middleware

const express = require("express");
const app = express();

app.use((req, res, next) => {
  console.log(`\({req.method} \){req.url}`);
  next();
});

• app.use() applies the middleware to every request.

• You must call next() to let the pipeline continue!

2. Router-Level Middleware

Middleware attached to specific routers or sets of routes.

Example: Protect Admin Routes

const express = require("express");
const adminRouter = express.Router();

adminRouter.use((req, res, next) => {
  if (!req.user || !req.user.isAdmin) {
    return res.status(403).send("Forbidden");
  }
  next();
});

adminRouter.get("/dashboard", (req, res) => {
  res.send("Admin Dashboard");
});

You attach the router to the app (app.use("/admin", adminRouter);) and only /admin routes will use that middleware.

3. Built-In Middleware

Express provides built-in middleware for common needs:

• express.json() – Automatically parses incoming JSON requests.

• express.urlencoded() – Parses URL-encoded form data.

• express.static() – Serves static files like images or CSS.

Example:

app.use(express.json());

Now every incoming JSON body is parsed and accessible as req.body.

Execution Order of Middleware in Express

Order matters!
Express runs middleware in the order you define it.

app.use(middlewareA);
app.use(middlewareB);

app.get("/hello", routeHandler);

• A request goes to middlewareA first, then middlewareB, then routeHandler.

• If any middleware does not call next(), the request halts immediately and never reaches the route.

Middleware can:

• Continue to the next function (next())

• End the response (res.send())

• Pass errors to the next error handler (next(err))

Role of the next() Function

• next() is how you tell Express to “move on” to the next thing in the pipeline.

• Without next(), the request will hang forever (unless you send a response).

• You can call next(err) to signal an error and invoke error-handling middleware.

Middleware Execution Sequence: A Visual Example

Consider:

app.use((req, res, next) => {
  console.log("First middleware");
  next();
});

app.use((req, res, next) => {
  console.log("Second middleware");
  next();
});

app.get("/", (req, res) => {
  res.send("Done!");
});

Request to / will print:

First middleware
Second middleware

And then respond with Done!.

If you send a response inside middleware (e.g., res.send("403 Forbidden")), Express skips all the remaining middleware and routes.

Real-World Examples of Middleware

1. Logging All Requests

app.use((req, res, next) => {
  console.log(`\({req.method} \){req.url} at ${new Date()}`);
  next();
});

2. Authentication “Checkpoint”

function authenticate(req, res, next) {
  if (!req.user) {
    return res.status(401).send("Unauthorized");
  }
  next();
}
app.use("/dashboard", authenticate);

3. Request Validation

function validateUserInput(req, res, next) {
  if (!req.body.username || !req.body.password) {
    return res.status(400).json({ error: "Missing fields" });
  }
  next();
}
app.post("/signup", validateUserInput, (req, res) => {
  // Create user
});

• If validation fails, middleware ends the cycle with a 400 response.

• If it passes, the actual signup route runs.

Request Pipeline Analogy

Imagine each call as passing through a pipeline of functions:

• Middleware 1: Add user info if logged in

• Middleware 2: Validating input.

• Middleware 3: Log the request

• Route Handler: Handle the request and send the response.

Each middleware can inspect, modify or even stop the request before it finally reaches the actual route handler.

Best Practices & Notes

• Put global middleware (e.g logging, json parsing) as soon as possible.

• Use router-level middleware for features that are only needed on some route groups (like admin auth)

• Always call ​ unless you send a response or encounter an error.

• The order of middleware is important . Earlier middleware can influence later middleware and route handlers .

• Middleware can also return errors / responses, which stops the pipeline.line.

Conclusion

In Express, middleware is a chain of functions that execute during the lifecycle of a request to the server. It enables you to:

• Add features and behaviour to your app without changing route handlers

• Reuse common processing logic (authentication, logging, input validation, etc.)

• Manage the flow of requests and responses

Understanding middleware can give you a very powerful way to control every request in your Express application. It makes your code modular, testable and maintainable.

React is fast because of the Virtual DOM

1. But what exactly is the Virtual DOM?

2. Why was it created?

3. And how does React use it to update the UI efficiently?

In this article, you will learn the complete flow of how React updates the screen. From rendering the components, comparing the changes, and updating only what is necessary.

By the end, you’ll clearly understand:

• What problem does Virtual DOM solve What problem does Virtual DOM solve

• Real DOM vs Virtual DOM Real DOM vs Virtual DOM

• How React renders the components How React renders the components

• When states change what happens When states change what happens

• What is diffing and reconciliation? What is diffing and reconciliation?

• How fast are React updates? How fast are React updates?

Let’s start from the beginning.

The Problem with Direct DOM Manipulation

Before React, developers would directly manipulate the browser’s Real DOM via JavaScript.

Example:

<h1 id="title">Hello</h1>

<script>
  document.getElementById("title").innerText = "Hello React";
</script>

This works perfectly for small applications.

But the applications today are huge.

• Social media feeds

• Dashboards(2)

• Chat applications

• E-commerce sites

In big apps, the UI is always changing.

So every small change in the Real DOM will affect the performance in a bad way. This is because DOM operations are expensive to browsers .

The browser may need to each time the DOM changes:

• Recalculate Layouts

• Repaint parts

• Re-render portions of the page

Doing this repeatedly can drastically reduce performance.

That’s the main problem React tries to solve.

What is the Real DOM?

The Real DOM is the actual structure of elements rendered in the browser.

Example structure:

<body>
  <div>
    <h1>Hello</h1>
    <button>Click</button>
  </div>
</body>

The browser converts this HTML into a tree-like structure called the DOM Tree.

Real DOM Features

• Connected directly to the browser

• Updating is comparatively costlier Updating is comparatively costlier

• Frequent updates will slow applications

• Any change may result in re-rendering work Any change may result in re-rendering work

What is the Virtual DOM?

The Virtual DOM is a lightweight JavaScript representation of the Real DOM.

Instead of changing the browser DOM directly, React first creates a virtual copy in memory.

Example Virtual DOM representation:

{
  type: "h1",
  props: {
    children: "Hello"
  }
}

This is not the real browser DOM.

It is just a JS object describing how the UI should look like.

JavaScript objects are very light weight and React can work with them very efficiently.

Initial Render Process in React

When a React app loads for the first time, React performs an initial render.

The flow looks like this:

React Component
       ↓
Creates Virtual DOM
       ↓
Converts to Real DOM
       ↓
Browser displays UI

Example Component

function App() {
  return <h1>Hello React</h1>;
}

React converts this JSX into a Virtual DOM object.

Then React creates the actual DOM node and displays it in the browser.

What Happens When State Changes?

React applications are dynamic.

Data changes constantly through:

• User input

• API responses

• Button clicks

• State updates

• Prop changes

Example:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>{count}</h1>

      <button onClick={() => setCount(count + 1)}>
        Increase
      </button>
    </div>
  );
}

When the button is clicked:

setCount(count + 1);

React does not immediately rebuild the whole browser DOM.

Instead, React follows a smarter process.

React Life Cycle

When state or props change:

1. React builds a new virtual DOM tree

2. React compares with the previous tree

3. React detects differences

4. React only updates changed parts in Real DOM.

This process is called

Reconcilliation

Creating a New Virtual DOM Tree

Suppose the counter changes from:

<h1>0</h1>

to:

<h1>1</h1>

React creates a new Virtual DOM representation.

Old Virtual DOM:

<h1>0</h1>

New Virtual DOM:

<h1>1</h1>

Now React compares both trees.

State Update and New Tree Diagram

What is Diffing?

This process of comparing the old and new virtual DOM trees is called diffing.

React checks

• What's changed

• What things stayed the same

• What things were added

• What was pulled out

React doesn't rebuild everything, it figures out the minimum number of changes needed.

Example:

Before:

<h1>0</h1>

After:

<h1>1</h1>

React notices:

• The <h1> element is the same

• Only the text content changed

So React updates only the text node.

This is much faster than replacing the entire element.

Here’s the complete lifecycle:

Component Render
       ↓
Virtual DOM Created
       ↓
State/Props Change
       ↓
New Virtual DOM Created
       ↓
Diffing (Comparison)
       ↓
Minimal Changes Found
       ↓
Real DOM Updated
       ↓
Browser Repaints UI

What is Reconciliation?

Reconciliation is React’s complete process of:

• Creating a new Virtual DOM

• Comparing it with the old one

• Finding differences

• Updating the Real DOM efficiently

You can think of reconciliation as:

“React figuring out the smartest way to update the UI.”

How React Finds the Minimum Changes

React has several internal optimisation techniques.

For the beginners, important concept is:

React updates only what actually changed.

Example:

<div>
  <h1>Hello</h1>
  <button>Click</button>
</div>

If only the button text changes:

<button>Submit</button>

React does not rebuild the entire <div>.

Only the button text gets updated.

This reduces expensive browser operations.

optimisation

The Virtual DOM improves performance because:

1. Reduces Direct DOM Operations

DOM manipulation is expensive.

React minimizes unnecessary updates.

2. Updates Only Changed Elements

Instead of rebuilding the whole UI, React patches only changed nodes.

3. Efficient Re-rendering

React can re-render components frequently without huge performance costs.

4. Better User Experience

Efficient updates create:

• Smoother animations

• Faster UI interactions

• Responsive applications

Important Clarification

Many beginners think:

“React never updates the Real DOM.”

That is incorrect.

React does update the Real DOM, but only after:

1. Creating Virtual DOM

2. Comparing changes

3. Finding minimal updates

The Virtual DOM acts like a smart middle layer.

Simple Mental Model for Beginners

You can think of React like this:

React creates a blueprint of the UI.
When data changes,
React creates a new blueprint,
compares it with the old one,
and updates only the changed parts.

That blueprint is the Virtual DOM.

Final Thoughts

React’s Virtual DOM is one of the most important concepts in React because it allows React to update the UI efficiently without doing unnecessary browser operations.

Instead of changing the Real DOM on every change, React takes a more intelligent approach:

• Create Virtual DOM

• Compare old and new versions

• Find differences

• Apply minimal updates

This is called reconciliation, and it helps keep React apps speedy and responsive when the UI changes a lot.

In traditional authentication systems, servers usually store user sessions in memory or databases. But modern applications often use a different approach called token-based authentication, especially with APIs and frontend frameworks like React or mobile apps.

One of the most popular token systems is JWT.

What is JWT

JWT stands for JSON Web Token. It is a compact string used to securely transfer user information between the client and the server. After login, the server generates a token and sends it to the user. The client stores that token and sends it with future requests.

This is called stateless authentication because the server does not need to store session data for every logged-in user.

A JWT looks something like this:

xxxxx.yyyyy.zzzzz

1. Header

The header stores information about the token type and algorithm.

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

The payload contains user-related data.

{
  "id": 101,
  "username": "pallab"
}

This data is called claims.

3. Signature

The signature is used to verify that the token was not modified.

The final token combines all three sections.

JWT Authentication Flow

Here is the overall login process:

User Login Request
        ↓
Server Verifies Credentials
        ↓
Server Generates JWT
        ↓
Client Stores Token
        ↓
Client Sends Token with Requests
        ↓
Server Verifies Token
        ↓
Protected Data Returned

This flow is widely used in REST APIs.

First install required packages.

npm install express jsonwebtoken bcryptjs

Now create a basic Express server.

const express = require("express");
const jwt = require("jsonwebtoken");

const app = express();

app.use(express.json());

Suppose a user logs in successfully.

app.post("/login", (req, res) => {
  const user = {
    id: 1,
    username: "pallab",
  };

  const token = jwt.sign(user, "secretkey", {
    expiresIn: "1h",
  });

  res.json({ token });
});

Here:

• jwt.sign() creates the token

• "secretkey" is used for verification

• expiresIn sets token expiration time

After login, the server sends the JWT to the client.

Example response:

{
  "token": "eyJhbGciOiJIUzI1NiIs..."
}

The frontend usually stores this token inside localStorage or cookies.

Now the client must send this token with future requests.

Most applications use the 'Authorisation' header.

Authorization: Bearer YOUR_TOKEN

The word Bearer Simply means the request is carrying a token.

Protecting Routes

JWT becomes useful when protecting private routes.

For example:

app.get("/profile", verifyToken, (req, res) => {
  res.json({
    message: "Protected profile data",
  });
});

Here verifyToken It is middleware that checks whether the token is valid.

Now create the middleware.

function verifyToken(req, res, next) {
  const bearerHeader = req.headers["authorization"];

  if (!bearerHeader) {
    return res.status(403).json({
      message: "Token missing",
    });
  }

  const token = bearerHeader.split(" ")[1];

  jwt.verify(token, "secretkey", (err, decoded) => {
    if (err) {
      return res.status(401).json({
        message: "Invalid token",
      });
    }

    req.user = decoded;
    next();
  });
}

This middleware does three important things:

1. Reads the token from headers

2. Verifies whether the token is valid

3. Allows access only if verification succeeds

If the token is missing or invalid, the route remains protected.

Route Protection Flow

Client Request
      ↓
Token Attached?
   Yes / No
      ↓
Server Verifies JWT
      ↓
Valid Token?
   Yes / No
      ↓
Access Granted or Denied

One major advantage of JWT authentication is scalability. Since the server does not store sessions, APIs become easier to scale across multiple servers.

JWT is commonly used in:

• REST APIs

• Mobile applications

• React applications

• Single Page Applications

• Microservices

However, JWT should still be handled carefully. Sensitive information should never be stored directly inside payloads because JWT payloads can be decoded easily.

Another important thing is token expiration. Tokens should expire after some time to improve security.

Today, JWT authentication is one of the most widely used authentication systems in modern backend development because it is lightweight, fast, and works extremely well with APIs and frontend frameworks. Understanding JWT properly is essential for anyone learning Express.js and modern web development.

When users submit text fields, Express can easily read them using middleware like express.json() OR. File uploads work differently because browsers send them using a special format called 'multipart/form-data'.

This format is designed for transferring binary data like images, PDFs, videos, and documents. Express cannot handle multipart form data by default. That is why middleware is required.

This is where Multer becomes useful.

Multer is a middleware for Express.js that handles file uploads easily. It processes incoming multipart form data and stores uploaded files on the server.

First, install Multer:

npm install multer

Now create a simple Express server.

const express = require("express");
const multer = require("multer");

const app = express();

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

Before handling uploads, we need a storage location. Usually, developers create a uploads folder where files will be stored.

Now configure multer storage.

const storage = multer.diskStorage({
  destination: function (req, file, cb) {
    cb(null, "uploads/");
  },

  filename: function (req, file, cb) {
    cb(null, Date.now() + "-" + file.originalname);
  },
});

const upload = multer({ storage: storage });

Here, it destination decides where files will be stored and filename controls the final file name.

The Date.now() part prevents duplicate filenames.

Now let’s handle a single file upload.

app.post("/upload", upload.single("image"), (req, res) => {
  res.send("File uploaded successfully");
});

upload.single("image") This means it's stored, and Multer expects one file with the field name "image".

Here is a simple HTML form for testing:

<form action="/upload" method="POST" enctype="multipart/form-data">
  <input type="file" name="image" />
  <button type="submit">Upload</button>
</form>

The enctype="multipart/form-data" Part is extremely important. Without it, the browser will not send the file correctly.

The upload flow looks something like this:

1. User selects a file

2. The browser sends multipart form-data

3. Multer middleware processes the request

4. The file gets stored inside the uploads folder

5. The server sends a response

This middleware sits between the request and the route handler. It extracts file data before the final route logic executes.

After uploading, Multer adds file information to req.file.

app.post("/upload", upload.single("image"), (req, res) => {
  console.log(req.file);

  res.send("Upload complete");
});

You will see details like the following:

{
  fieldname: 'image',
  originalname: 'photo.png',
  filename: '171234567-photo.png',
  path: 'uploads/photo.png'
}

Now let’s upload multiple files.

app.post("/photos", upload.array("photos", 3), (req, res) => {
  res.send("Multiple files uploaded");
});

Here:

• "photos" is the field name

• 3 is the maximum allowed file count

HTML form:

<form action="/photos" method="POST" enctype="multipart/form-data">
  <input type="file" name="photos" multiple />
  <button type="submit">Upload</button>
</form>

For multiple uploads, Multer stores file information inside req.files.

console.log(req.files);

One common beginner question is why middleware is needed at all.

Imagine Express receiving a large image file directly without processing. Express only understands raw request streams. Multer reads the multipart data, separates file content from normal form fields, and prepares everything in a usable format.

Without middleware, file handling would become much more complicated.

Another important feature is serving uploaded files back to users. Suppose someone uploads a profile picture and you want to display it later.

Express can expose the uploads folder publicly.

app.use("/uploads", express.static("uploads"));

Now uploaded files can be accessed using URLs like:

http://localhost:3000/uploads/photo.png

This is how many beginner-level image upload systems work.

Multer also supports file validation and limits. For example, you may want to allow only images.

const upload = multer({
  storage: storage,

  fileFilter: function (req, file, cb) {
    if (file.mimetype.startsWith("image/")) {
      cb(null, true);
    } else {
      cb(new Error("Only images allowed"));
    }
  },
});

This checks the MIME type before storing the file.

You can also limit file size.

const upload = multer({
  storage: storage,
  limits: {
    fileSize: 1024 * 1024,
  },
});

This allows files up to 1 MB.

In real-world applications, developers often upload files to cloud storage services like AWS S3 or Cloudinary. But for beginners, local storage is the best way to understand how uploads actually work.

Multer makes the entire upload process simple and organised. Instead of manually handling binary streams, developers can focus on application logic while Multer processes the files in the background.

Today, Multer is widely used in Express applications for handling profile pictures, documents, PDFs, videos, resumes, and many other types of uploads. Understanding Multer properly is an important step for anyone learning backend development with Node.js and Express.

Synchronous code runs one step at a time in order. JavaScript waits for the current task to finish before moving to the next one.

console.log("Start");
console.log("Process");
console.log("End");

Output:

Start
Process
End

The execution is simple and predictable.

Now imagine a task that takes 5 seconds. In synchronous programming, everything after it must wait.

console.log("Start");

function waitFiveSeconds() {
  const start = Date.now();

  while (Date.now() - start < 5000) {}
}

waitFiveSeconds();

console.log("End");

Here, the program freezes for 5 seconds before printing "End". This is called blocking code because other operations cannot continue until the task is complete.

Blocking becomes a serious problem in web applications. Users do not want the entire page to freeze while waiting for data.

That is why JavaScript uses asynchronous behaviour.

Asynchronous code allows long tasks to run in the background while JavaScript continues executing other code.

console.log("Start");

setTimeout(() => {
  console.log("Task Completed");
}, 2000);

console.log("End");

Output:

Start
End
Task Completed

Even though the timer takes 2 seconds, JavaScript does not stop the entire program. This is called 'non-blocking behaviour'.

A common real-world example is API calls.

console.log("Fetching data...");

fetch("https://api.example.com/data")
  .then((response) => response.json())
  .then((data) => {
    console.log(data);
  });

console.log("Other code running...");

Fetching data may take time depending on the internet speed, but JavaScript keeps running the remaining code.

You can think of asynchronous programming like ordering food in a restaurant. After placing the order, you do not stand inside the kitchen waiting. You continue talking with friends while the food is prepared in the background.

This non-blocking behaviour is one of the main reasons JavaScript can build fast and interactive web applications.

To solve this problem, JavaScript introduced asynchronous programming. Initially, developers only used callbacks. Afterwards, promises made things better. But as applications grew bigger, even promises began to produce code that looked hard to read and manage. That's why async/await was introduced in ES2017.

Async/await is not a completely new system. It is actually built on top of promises. You can think of it as syntactic sugar that makes asynchronous code look cleaner and easier to understand.

Before async/await, developers commonly wrote code like this:

function fetchData() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("Data received");
    }, 2000);
  });
}

fetchData()
  .then((result) => {
    console.log(result);
  })
  .catch((error) => {
    console.log(error);
  });

This works perfectly fine, but when multiple asynchronous operations are chained together, the code becomes harder to follow. Async/await solves this readability issue.

Here is the same example using async/await:

function fetchData() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("Data received");
    }, 2000);
  });
}

async function getData() {
  const result = await fetchData();
  console.log(result);
}

getData();

We put the async keyword before a function declaration. An async function always returns a promise.

The await keyword can be used inside an async function. Await pauses the execution of that function until the promise is fulfilled. It doesn't halt the entire JavaScript program. Only that specific async function is waiting. The rest of the app is running normally.

One of the biggest advantages of async/await is that it makes async code feel almost like sync code.

Cleaner error handling is another big advantage. Developers normally use .catch() to handle errors in promises. You can use standard try...catch blocks with async/await.

function loginUser() {
  return new Promise((resolve, reject) => {
    const success = false;

    if (success) {
      resolve("Login successful");
    } else {
      reject("Invalid credentials");
    }
  });
}

async function login() {
  try {
    const message = await loginUser();
    console.log(message);
  } catch (error) {
    console.log(error);
  }
}

login();

This style feels much more natural, especially when applications contain multiple asynchronous operations.

Consider a situation where data must be fetched step by step. Using chained promises can become messy very quickly. Async/await keeps the flow simple and readable.

async function processOrder() {
  const user = await getUser();
  const cart = await getCart(user);
  const payment = await makePayment(cart);

  console.log(payment);
}

Code is top to bottom like normal programming logic. This is why many developers are leaning towards async/await in modern JavaScript projects.

Though async/await makes for more readable code, it is still based on promises underneath. Every async function automatically returns a promise, regardless of whether you return a value or not.

Nowadays, async/await is widely used in frontend frameworks, backend applications, APIs, and database operations as it helps developers to write cleaner and more maintainable asynchronous code. Anyone working with modern JavaScript will have to get used to it properly.

This is where Express.js becomes important. Express is a lightweight framework built on top of Node.js that simplifies backend development by providing a cleaner and more organized way to handle servers and APIs.

What is Express.js?

Express.js is a minimal and flexible web framework for Node.js. It provides tools and features that make server-side development easier and faster.

Instead of manually checking request URLs, methods, and headers every time, Express gives developers built-in methods for routing, middleware handling, request parsing, and sending responses.

Without Express, even a simple API can quickly become messy.

A raw Node.js server usually looks like this:

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.method === "GET" && req.url === "/") {
    res.writeHead(200, {
      "Content-Type": "text/plain"
    });

    res.end("Welcome to Node.js Server");
  }
});

server.listen(3000);

Now compare that with Express:

const express = require("express");

const app = express();

app.get("/", (req, res) => {
  res.send("Welcome to Express Server");
});

app.listen(3000);

Both servers do the same thing, but the Express version is much shorter, cleaner, and easier to understand.

This simplicity becomes extremely valuable when applications contain many routes and features.

Why Express Simplifies Node.js Development

Express removes a lot of repetitive work that developers normally do with the native http module.

Some major advantages include:

• Cleaner routing system

• Easy request handling

• Middleware support

• Better code organization

• Faster API development

• Easy integration with databases and frontend applications

Express also makes code more readable for teams working on large projects.

Instead of manually checking every request condition, developers can define dedicated route handlers like this:

app.get("/products", handlerFunction);

app.post("/products", createProduct);

This structure keeps applications modular and scalable.

Creating Your First Express Server

Before building a server, install Express inside your project.

npm init -y
npm install express

Now create a file named server.js.

const express = require("express");

const app = express();

const PORT = 5000;

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Run the server using:

node server.js

Your Express server is now active.

Understanding Express Routing

Routing means deciding what response should be sent when a user visits a particular URL.

Express handles routing using methods like:

• app.get()

• app.post()

• app.put()

• app.delete()

Here’s a simple visualization of how Express processes requests:

Client Request
       │
       ▼
Express Route Handler
       │
       ▼
Response Sent Back

Each route contains:

1. HTTP method

2. URL pat

3. Callback function

Example:

app.get("/about", (req, res) => {
  res.send("About Page");
});

When someone visits /about, Express executes the callback function and sends the response.

Handling GET Requests in Express

GET requests are mainly used for fetching or reading data from the server.

Example of a basic GET route:

app.get("/students", (req, res) => {
  const students = [
    { id: 1, name: "Rahul" },
    { id: 2, name: "Aman" }
  ];

  res.json(students);
});

Here:

• req contains request information

• res is used to send the response

Route Parameters

Express allows dynamic routes using parameters.

app.get("/students/:id", (req, res) => {
  const studentId = req.params.id;

  res.send(`Student ID is ${studentId}`);
});

If the URL becomes:

/students/10

The output will be:

Student ID is 10

Query Parameters

Query strings are useful for filtering or pagination.

app.get("/search", (req, res) => {
  const keyword = req.query.keyword;

  res.send(`Searching for ${keyword}`);
});

Request:

/search?keyword=laptop

Response:

Searching for laptop

Handling POST Requests in Express

POST requests are used to send data from the client to the server.

To handle JSON request bodies, Express provides middleware.

app.use(express.json());

Now create a POST route:

app.post("/register", (req, res) => {

  const { username, email } = req.body;

  if (!username || !email) {
    return res.status(400).json({
      message: "All fields are required"
    });
  }

  const newUser = {
    id: Date.now(),
    username,
    email
  };

  res.status(201).json(newUser);
});

Example request body:

{
  "username": "Pallab",
  "email": "pallab@gmail.com"
}

The server receives the data using req.body and sends a JSON response.

Sending Responses in Express

Express provides multiple methods for sending responses.

Sending Plain Text

res.send("Server Working");

Sending JSON Data

res.json({
  success: true
});

Sending Status Codes

res.status(404).send("Page Not Found");

Combining Status and JSON

res.status(200).json({
  message: "Login Successful"
});

These response methods make API development much simpler compared to raw Node.js.

Building a Small Express API

Now let’s combine everything into one mini project.

const express = require("express");

const app = express();

app.use(express.json());

const books = [
  { id: 1, title: "Atomic Habits" }
];

app.get("/books", (req, res) => {
  res.json(books);
});

app.get("/books/:id", (req, res) => {

  const book = books.find(
    b => b.id === parseInt(req.params.id)
  );

  if (!book) {
    return res.status(404).json({
      message: "Book not found"
    });
  }

  res.json(book);
});

app.post("/books", (req, res) => {

  const { title } = req.body;

  if (!title) {
    return res.status(400).json({
      message: "Title is required"
    });
  }

  const newBook = {
    id: books.length + 1,
    title
  };

  books.push(newBook);

  res.status(201).json(newBook);
});

app.listen(3000, () => {
  console.log("Server started");
});

This small application demonstrates:

• GET requests

• POST requests

• Route parameters

• JSON responses

• Status codes

• Middleware usage

These are the same concepts used in real-world backend applications.

Final Thoughts

Express.js has become one of the most popular backend frameworks because it simplifies server development without hiding the core concepts of Node.js.

Instead of spending time handling low-level server logic manually, developers can focus on building features, APIs, authentication systems, and databases more efficiently.

For beginners, Express provides a clean introduction to backend development. For experienced developers, it offers flexibility and speed for building scalable applications.

To solve these issues, JavaScript introduced Map and Set in ES6. These modern data structures provide cleaner syntax, better performance in many cases, and more flexibility for handling complex data.

What is a Map in JavaScript?

A Map is a special collection that stores data in key-value format. Unlike regular Objects, a Map allows keys of any data type, including numbers, objects, and even functions.

In simple words, a Map is used to connect one value with another value using flexible keys.

const studentMarks = new Map();

const studentA = { id: 1 };
const studentB = { id: 2 };

studentMarks.set(studentA, 85);
studentMarks.set(studentB, 92);

console.log(studentMarks.get(studentA));
console.log(studentMarks.size);

Output:

85
2

Here, objects are being used directly as keys, which is not possible in a normal Object without converting them into strings.

Why Use a Map Instead of an Object?

One major advantage of Map is that it does not come with unwanted predefined keys like constructor or toString. It only stores the data you add manually.

Maps also preserve insertion order, making iteration predictable. Another benefit is performance. When applications frequently add or remove data, Maps are generally faster and more memory efficient.

Map vs Object

What is Set?

A Set is a collection where duplicate values are automatically removed. Every item inside a Set must be unique.

const activeUsers = new Set();

activeUsers.add("Rahul");
activeUsers.add("Ankit");
activeUsers.add("Rahul");

console.log(activeUsers.size);
console.log(activeUsers.has("Ankit"));

Output:

2
true

Even though "Rahul" was added twice, the Set stored it only once.

Why Use Set Instead of Array?

Arrays allow duplicate values, which can create unnecessary complexity when uniqueness matters. Sets solve this problem automatically.

Searching inside a Set is also much faster than using methods like includes() on large Arrays.

Set vs Array

Real-World Use Cases

A Map is useful in applications like inventory systems, caching, or storing user session data, where keys may not always be strings.

A Set is perfect for tracking unique hashtags, online users, email subscribers, or filtering duplicate data from APIs.

Conclusion

Map and Set are modern JavaScript features designed to make data handling more efficient and readable. While Objects and Arrays are still important, using Map and Set in the right situations can improve performance, reduce bugs, and make your code much cleaner. For modern JavaScript development, understanding these structures is extremely valuable.

A callback function is simply a function that is passed as an argument to another function and executed later. Instead of running immediately, the function waits until another operation finishes.

Here is a very simple example:

function greet(name) {
    console.log("Hello " + name);
}

function processUser(callback) {
    const user = "Pallab";
    callback(user);
}

processUser(greet);

In this example, the greet function is passed into processUser as a callback. When processUser runs, it executes the callback function and sends the username as an argument.

Callbacks are heavily used because JavaScript works asynchronously in many situations. Some tasks take time to complete, such as reading files, fetching data from an API, or waiting for user input. JavaScript does not stop the entire program while waiting for these tasks. Instead, it continues running other code and executes the callback once the task is completed.

A common asynchronous example is setTimeout.

console.log("Start");

setTimeout(function () {
    console.log("This runs after 2 seconds");
}, 2000);

console.log("End");

The output will be:

Start
End
This runs after 2 seconds

The timeout function runs later, while the rest of the program continues immediately. This is one of the core ideas behind asynchronous programming in JavaScript.

Callbacks are also common in array methods. Functions like map, filter, and forEach all use callbacks internally.

const numbers = [1, 2, 3];

numbers.forEach(function (num) {
    console.log(num * 2);
});

Here, the callback function runs once for every item inside the array.

Another real-world use case is handling API requests. Earlier JavaScript applications relied heavily on callbacks for server communication.

function fetchData(callback) {
    setTimeout(() => {
        const data = { id: 1, title: "JavaScript Guide" };
        callback(data);
    }, 1000);
}

fetchData(function (response) {
    console.log(response.title);
});

The callback only executes after the simulated API request finishes.

Although callbacks are powerful, too many nested callbacks can make code difficult to read and maintain. This problem is often called "callback hell".

loginUser(function(user) {
    getProfile(user, function(profile) {
        getPosts(profile, function(posts) {
            console.log(posts);
        });
    });
});

As nesting increases, the code becomes harder to debug and understand. This was one of the major reasons JavaScript introduced Promises and later async/await.

Even though modern JavaScript now uses newer asynchronous patterns, understanding callbacks is still extremely important. Many browser APIs, event listeners, and Node.js functions still rely on callbacks internally.

Callback functions teach one of the most important ideas in JavaScript: functions are not just reusable blocks of code, they can also control how and when other code executes. Once this concept becomes clear, learning advanced topics like Promises, asynchronous APIs, and event-driven programming becomes much easier.

For intermediate and advanced developers, destructuring is more than just shorthand syntax. It improves readability, simplifies function handling, reduces repetitive code, and makes working with APIs or large data structures easier.

What Destructuring Means

Destructuring is a JavaScript feature that lets you unpack values from arrays or properties from objects directly into variables.

Without destructuring, developers usually access values one by one:

const user = {
  name: "Pallab",
  role: "Developer",
  experience: 3
};

const name = user.name;
const role = user.role;
const experience = user.experience;

With destructuring:

const user = {
  name: "Pallab",
  role: "Developer",
  experience: 3
};

const { name, role, experience } = user;

The second approach is shorter, cleaner, and easier to maintain.

Destructuring Arrays

Array destructuring extracts values based on their position.

Basic Example

const colors = ["red", "blue", "green"];

const [first, second, third] = colors;

console.log(first);  // red
console.log(second); // blue
console.log(third);  // green

Here:

• first gets the first value

• second gets the second value

• third gets the third value

Skipping Values

Sometimes developers only need specific values.

const numbers = [10, 20, 30, 40];

const [first, , third] = numbers;

console.log(first); // 10
console.log(third); // 30

The empty space skips unwanted values.

Using Rest Operator

The rest operator collects remaining items.

const tools = ["VS Code", "Git", "Docker", "Postman"];

const [mainTool, ...otherTools] = tools;

console.log(mainTool);
console.log(otherTools);

Output:

VS Code
["Git", "Docker", "Postman"]

This is useful when handling dynamic arrays.

Destructuring Objects

Object destructuring extracts properties using property names instead of positions.

Basic Object Destructuring

const server = {
  host: "localhost",
  port: 3000,
  protocol: "https"
};

const { host, port, protocol } = server;

console.log(host);
console.log(port);

Renaming Variables

Advanced applications often require cleaner or safer variable names.

const user = {
  username: "dev_pallab",
  email: "pallab@example.com"
};

const { username: userName, email: userEmail } = user;

console.log(userName);
console.log(userEmail);

Here:

• username becomes userName

• email becomes userEmail

This avoids naming conflicts in large codebases.

Nested Object Destructuring

Real-world applications frequently use deeply nested data from APIs.

const response = {
  status: 200,
  data: {
    profile: {
      fullName: "Pallab Karmakar",
      skills: ["JavaScript", "Node.js"]
    }
  }
};

const {
  data: {
    profile: { fullName, skills }
  }
} = response;

console.log(fullName);
console.log(skills);

Nested destructuring reduces repeated property access.

Default Values

Default values prevent undefined errors when properties or array items are missing.

Array Defaults

const settings = ["dark"];

const [theme, layout = "grid"] = settings;

console.log(theme);
console.log(layout);

Output:

dark
grid

Object Defaults

const config = {
  apiUrl: "https://example.com"
};

const { apiUrl, timeout = 5000 } = config;

console.log(timeout);

This technique is extremely useful in configuration-based applications.

Before vs After Destructuring

Without Destructuring

const employee = {
  id: 101,
  department: "Engineering",
  salary: 80000
};

const id = employee.id;
const department = employee.department;
const salary = employee.salary;

With Destructuring

const employee = {
  id: 101,
  department: "Engineering",
  salary: 80000
};

const { id, department, salary } = employee;

The destructured version is:

• More readable

• Easier to scale

• Less repetitive

• Cleaner during refactoring

Destructuring in Function Parameters

Advanced developers frequently use destructuring directly inside function parameters.

function createUser({ name, role, isAdmin = false }) {
  console.log(name);
  console.log(role);
  console.log(isAdmin);
}

createUser({
  name: "Pallab",
  role: "Backend Developer"
});

Benefits:

• Cleaner parameter handling

• Built-in defaults

• Better readability

• Easier API integration

This pattern is heavily used in React, Express.js, and Node.js applications.

Benefits of Destructuring

Reduces Repetitive Code

Instead of repeatedly writing object references, developers can extract values once and use them directly.

Improves Readability

Clean variable extraction makes code easier to understand for teams and collaborators.

Better API Handling

Modern APIs return nested JSON structures. Destructuring helps simplify data extraction.

const {
  data: { token }
} = apiResponse;

Cleaner Function Signatures

Functions become easier to maintain when using object destructuring with defaults.

Works Well with Modern Frameworks

Libraries and frameworks like:

• React

• Next.js

• Express.js

• Vue

• Node.js

Heavily relies on destructuring patterns.

Example from Express:

const { id } = req.params;
const { search } = req.query;

Common Mistakes Developers Make

Destructuring Undefined Values

const { name } = undefined;

This throws an error.

Safer approach:

const { name } = user || {};

Variable Name Conflicts

Avoid extracting variables with names already used in scope.

Use renaming:

const { id: userId } = user;

Final Thoughts

Destructuring is no longer just a modern JavaScript feature. It has become a standard practice in professional development. Intermediate and advanced developers use it daily to write concise, scalable, and maintainable code.

Whether you are working with API responses, React props, Express request objects, configuration files, or database results, destructuring helps simplify complex code structures.

At first, both may look similar because they both send values through the URL. But in real-world development, they are used for different purposes. Understanding when to use each one makes your API cleaner and easier to understand.

Your reference explained this idea using a library example.
In this article, we will understand these concepts in a more practical way using different examples.

Understanding URL Structure

Take a look at this URL:

http://localhost:3000/products/25/reviews?page=2&sort=latest

This URL contains both route parameters and query strings.

Breakdown:

/products/25/reviews

This part is the route path.

25

This is a URL parameter because it identifies a specific product.

Now look at this part:

?page=2&sort=latest

These are query strings because they change how the data is returned.

The ? The symbol separates the main route from the query values.

What are URL Parameters?

URL parameters are values written directly inside the route path. They are mainly used to identify a specific resource.

For example:

/products/25

Here, 25 could represent the ID of a product.

Another example:

/students/102

This route refers to a particular student.

In Express.js, parameters are created using a colon :.

Example:

const express = require("express");
const app = express();

app.get("/students/:studentId", (req, res) => {
  res.send(req.params);
});

app.listen(3000);

If the user visits:

/students/102

The output will be:

{
  studentId: "102"
}

Express stores all route parameters inside:

req.params

Multiple URL Parameters

You can also use more than one parameter in the same route.

Example:

app.get("/courses/:courseId/lessons/:lessonId", (req, res) => {
  res.send(req.params);
});

Request:

/courses/12/lessons/5

Output:

{
  courseId: "12",
  lessonId: "5"
}

This is useful when one resource belongs to another resource.

What are Query Strings?

Query strings are optional values added after the ? symbol in a URL. They are mostly used for filtering, searching, sorting, or pagination.

Example:

/products?category=mobile

Here, we are requesting products, but only from the mobile category.

Another example:

/movies?year=2025&rating=8

This route asks for movies filtered by year and rating.

In Express.js, query strings are available inside:

req.query

Example:

app.get("/movies", (req, res) => {
  res.send(req.query);
});

Request:

/movies?year=2025&rating=8

Output:

{
  year: "2025",
  rating: "8"
}

Important Point About Query Values

Everything received from req.query is treated as a string.

Example:

app.get("/items", (req, res) => {
  const page = parseInt(req.query.page) || 1;

  res.send(`Current page: ${page}`);
});

Request:

/items?page=3

Output:

Current page: 3

Without parseInt(), the value would remain a string.

Difference Between Params and Query Strings

When Should You Use URL Parameters?

Use URL parameters when the value is necessary to identify something specific.

Example:

/orders/500

Without the order ID, the request does not make sense.

Express example:

app.get("/orders/:orderId", (req, res) => {
  res.send(`Order ID: ${req.params.orderId}`);
});

When Should You Use Query Strings?

Use query strings when the route can still work without the value.

Example:

/products?sort=price

Even without sorting, /products still works.

Another example:

/articles?tag=nodejs

This only filters articles by tag.

Express example:

app.get("/articles", (req, res) => {
  const tag = req.query.tag;

  res.send(`Filtering by tag: ${tag}`);
});

Combining Both Together

In real projects, both are often used in the same route.

Example:

app.get("/teachers/:teacherId/classes", (req, res) => {
  const teacherId = req.params.teacherId;
  const subject = req.query.subject;

  res.send({
    teacherId,
    subject
  });
});

Request:

/teachers/45/classes?subject=math

Output:

{
  teacherId: "45",
  subject: "math"
}

Here:

• teacherId identifies the teacher

• subject filters the classes

Common Mistakes

Many beginners place filters inside the route path.

Wrong:

/products/electronics

This looks like electronics is a product ID or product name.

Better:

/products?category=electronics

Another example:

Wrong:

/news/latest

Better:

/news?sort=latest

Final Thoughts

URL parameters and query strings are both important parts of Express.js routing. Even though they look similar, their purpose is different.

• URL parameters help identify a specific resource.

• Query strings help modify or filter data.

A simple way to remember:

• Params → Which item?

• Query → How should the result look?

Node.js allows us to run JavaScript outside the browser. It is built on Chrome’s V8 JavaScript engine and is mainly used for backend development, APIs, real-time apps, and automation tools.

Before building applications with Node.js, it is important to understand how to install it, run JavaScript files, and use the Node runtime properly.

Installing Node.js

To install Node.js, go to the official website of Node.js and download the LTS (Long Term Support) version.

The installation process is mostly the same for all operating systems:

• Download the installer

• Run the setup

• Keep the default options

• Finish installation

Node.js also installs npm (Node Package Manager) automatically, which is used to install packages later.

Checking the Installation

After installation, open your terminal or command prompt and run:

node -v

This shows the installed Node.js version.

Example:

v24.1.0

Now check npm:

npm -v

If both commands return versions, Node.js is installed correctly.

Understanding Node REPL

Before writing actual files, Node.js provides something called the REPL.

REPL stands for:

• Read

• Evaluate

• Print

• Loop

It is an interactive environment where we can write JavaScript directly in the terminal and instantly see the output.

Start the REPL using:

node

Now you can write JavaScript:

2 + 2

Output:

4

Another example:

const name = "Pallab";
console.log(name);

The REPL is useful for testing small snippets quickly without creating files.

To exit the REPL:

.exit

Creating Your First JavaScript File

Now let’s create a real JavaScript file.

Create a file named:

app.js

Inside the file write:

console.log("Hello from Node.js");

Save the file.

Running a Script Using Node

Open the terminal in the same folder where the file exists and run:

node app.js

Output:

Hello from Node.js

Here, Node.js takes the JavaScript file, executes it inside the runtime, and prints the output in the terminal.

Node Execution Flow

JavaScript File
       ↓
Node Runtime
       ↓
V8 Engine Executes Code
       ↓
Output in Terminal

This is the basic execution flow of Node.js.

Writing Your First Hello World Server

Node.js can also create servers using built-in modules.

Create a file named:

server.js

Add this code:

const http = require("http");

const server = http.createServer((req, res) => {
  res.end("Hello World");
});

server.listen(3000, () => {
  console.log("Server running on port 3000");
});

Run it using:

node server.js

Now open your browser and visit:

http://localhost:3000

You will see:

Hello World

Script to Runtime Flow

server.js
    ↓
Node Runtime Starts
    ↓
HTTP Server Created
    ↓
Listening on Port 3000
    ↓
Browser Sends Request
    ↓
Server Sends Response

Conclusion

Node.js makes it possible to run JavaScript outside the browser. After installing it, we can use the REPL for quick testing, execute JavaScript files using the node command, and even create servers with built-in modules.

These are the core basics every Node.js developer should understand before moving into frameworks and backend development.

During software building, or we can say the coding process, one of the most important and skill full part is error-handling. No matter how well an application is written, errors can still happen during execution. A user may enter invalid data, an API request may fail, a file may not exist, or unexpected values may break the logic of the application.

If errors are not handled properly, applications can crash, freeze, or behave unpredictably. Good error handling helps developers prevent these problems and makes applications more stable and reliable.

JavaScript provides built-in mechanisms such as try, catch, finally, and throw to manage runtime errors properly.

What Are Errors in JavaScript?

An error occurs in JavaScript when the engine can't execute the code successfully. When JavaScript finds an issue that it cannot handle automatically, it throws an error object & if the error is not handled properly, it stops execution.

Example:

console.log(userName);

Output:

ReferenceError: userName is not defined

In this example, JavaScript throws a ReferenceError because the variable does not exist.

Types of Errors in JavaScript

JavaScript includes multiple built-in error types. Each type represents a different category of problem.

ReferenceError

A ReferenceError occurs when code tries to access a variable that has not been declared.

Example:

console.log(totalAmount);

Output:

ReferenceError: totalAmount is not defined

This error usually happens due to a misspelled variable name, a variable outside scope, use variable before declaration.

TypeError

A TypeError happens when an operation is performed on an incompatible value.

Example:

const number = 100;

number.toUpperCase();

Output:

TypeError: number.toUpperCase is not a function

Here, toUpperCase() works only on strings, not numbers.

Common causes of TypeError include:

• Calling methods on incorrect data types

• Accessing properties of undefined

• Using array methods on non-arrays

SyntaxError

A SyntaxError occurs when the structure of the code is invalid.

Example:

if (true {
  console.log("Hello");
}

Output:

SyntaxError: Unexpected token '{'

JavaScript cannot execute code with invalid syntax because it fails during parsing.

Common reasons include:

• Missing brackets

• Missing commas

• Incorrect operators

• Invalid JavaScript structure

RangeError

A RangeError occurs when a value goes outside the allowed range.

Example:

const items = new Array(-2);

Output:

RangeError: Invalid array length

This error usually happens when:

• Array lengths become invalid

• Recursive functions exceed limits

• Numeric values go outside accepted boundaries

URIError

A URIError occurs when URI-related functions receive invalid input.

Example:

decodeURIComponent("%");

Output:

URIError: URI malformed

This type of error is less common but can happen while working with URLs or encoded data.

Why Error Handling Is Important

Error handling is important because real-world applications constantly deal with unpredictable situations.

Without proper handling:

• Applications may crash

• Users may lose data

• Systems may become unstable

• Debugging becomes difficult

Improves User Experience

Users should never see broken screens or confusing crashes.

Instead of crashing completely, applications should display meaningful messages.

Example:

try {
  const response = JSON.parse(invalidData);
} catch (error) {
  console.log("Unable to process data");
}

This keeps the application running even when invalid data appears.

Makes Debugging Easier

Errors provide details about:

• What went wrong

• Where the issue occurred

• Which line caused the problem

Example:

TypeError: Cannot read properties of undefined

This information helps developers fix issues faster.

Prevents Invalid Data

Sometimes invalid values can spread through an application silently.

Example:

const result = Number("abc");

console.log(result);

Output:

NaN

If this value continues into calculations or databases, it may create larger problems later.

Error handling allows developers to stop invalid operations early.

Improves Application Stability

Applications that handle failures gracefully are more reliable.

Even if one operation fails, the rest of the system can continue working normally.

This is especially important in:

• Banking systems

• Payment gateways

• Authentication systems

• APIs

• Database applications

The try...catch Statement

JavaScript provides the try...catch statement to handle runtime errors.

The try block contains code that may fail.

The catch block handles errors if they occur.

Syntax:

try {
  // risky code
} catch (error) {
  // error handling
}

Example of try...catch

try {
  const user = JSON.parse("{name:'Pallab'}");

  console.log(user);
} catch (error) {
  console.log("Invalid JSON format");
}

Output:

Invalid JSON format

Understanding the Error Object

The catch block receives an error object.

This object contains useful information about the error.

Example:

try {
  const data = JSON.parse("invalid json");
} catch (error) {
  console.log(error.name);
  console.log(error.message);
}

Output:

SyntaxError
Unexpected token i in JSON at position 0

The finally Block

The finally block always executes whether an error occurs or not.

It is mainly used for cleanup operations.

Syntax:

try {
  // code
} catch (error) {
  // handle error
} finally {
  // always runs
}

Example of finally

try {
  console.log("Connecting to database");
} catch (error) {
  console.log("Database error");
} finally {
  console.log("Closing database connection");
}

Output:

Connecting to database
Closing database connection

Throwing Custom Errors

JavaScript also allows developers to create custom errors using the throw keyword.

This is useful when application-specific rules need validation.

Syntax:

throw new Error("Message");

Example of Custom Error

function registerUser(age) {
  if (age < 18) {
    throw new Error("User must be at least 18 years old");
  }

  return "Registration successful";
}

try {
  console.log(registerUser(15));
} catch (error) {
  console.log(error.message);
}

Output:

User must be at least 18 years old

Here, JavaScript itself sees no technical problem, but the application logic requires age validation.

Creating Custom Error Classes

Developers can also create their own error classes.

Example:

class ValidationError extends Error {
  constructor(message) {
    super(message);
    this.name = "ValidationError";
  }
}

throw new ValidationError("Invalid email address");

Custom error classes help organize large applications more effectively.

Nested try...catch

JavaScript allows nested error handling.

Example:

try {
  try {
    JSON.parse("invalid");
  } catch (error) {
    console.log("Inner catch block");
  }
} catch (error) {
  console.log("Outer catch block");
}

This is useful in complex applications where different layers handle different errors.

Error Handling in Async Code

Errors can also happen in asynchronous operations.

For async functions, try...catch it works together with async/await.

Example:

async function fetchData() {
  try {
    const response = await fetch("https://api.example.com/data");

    const data = await response.json();

    console.log(data);
  } catch (error) {
    console.log("Failed to fetch data");
  }
}

This helps handle API failures safely.

Best Practices for Error Handling

Handle Errors Properly

Never ignore errors completely.

Bad practice:

catch (error) {

}

Always log or handle errors meaningfully.

Use Specific Error Messages

Good error messages make debugging easier.

Bad:

throw new Error("Something went wrong");

Better:

throw new Error("Password must contain at least 8 characters");

Avoid Exposing Sensitive Information

Do not show internal server details directly to users.

Bad:

Database connection failed at port 3306

Better:

Unable to process request right now

Use finally for Cleanup

Always clean resources properly.

Example:

finally {
  connection.close();
}

Conclusion

Error handling is a core part of JavaScript development. Applications cannot rely on everything working all the time perfectly. Failures are normal in software systems, and handling them properly is what makes applications reliable.

If you have worked with modern JavaScript, you have probably seen the triple-dot syntax:

...

At first, this syntax can feel confusing because the same symbol is used for two completely different behaviors. Mainly expands and collects values. This is the actual reason why most developers mess up in interviews.

The important thing to understand is:

• Spread Operator → Expands values

• Rest Operator → Collects values

Even though both use the same ... The syntax of their behavior depends entirely on where they are used.

Understanding the Idea with a Simple Analogy

Imagine there is a backup filled with all your items.

Spread Operator

You open the backpack and place every item separatly on the table. Here you are taking things out of the backpack.

Backpack → Notebook, Charger, Mouse

This is exactly what the spread operator does. It takes grouped values and expands them into individual items.

Rest Operator

Now imagine loose items scattered on a table.

You collect all of them and put them into one backpack. Here you are collecting scattered items and putting them again on backpack

Notebook + Charger + Mouse → Backpack

That is how the rest operator works. It gathers multiple values into a single collection.

What is the Spread Operator?

The spread operator expands values from:

• Arrays

• Objects

• Strings

• Iterables

Commonly used for coping, margin, cloning, and passing multiple arguments.

Spread Operator with Arrays

Suppose you are building a reading app and want to combine two book lists.

const sciFiBooks = ['Dune', 'Foundation'];
const fantasyBooks = ['Harry Potter', 'The Hobbit'];

const library = [...sciFiBooks, ...fantasyBooks, 'Atomic Habits'];

console.log(library);

Output

[
  'Dune',
  'Foundation',
  'Harry Potter',
  'The Hobbit',
  'Atomic Habits'
]

Copying Arrays with Spread

Without spread, copying arrays manually becomes repetitive.

const original = [10, 20, 30];

const copied = [...original];

console.log(copied);

Output

[10, 20, 30] 

Spread Operator with Objects

Spread is also extremely useful when working with objects.

const userProfile = {
  username: 'pallab',
  verified: false
};

const updatedProfile = {
  ...userProfile,
  verified: true
};

console.log(updatedProfile);

Output

{
  username: 'pallab',
  verified: true
}

Why Developers Use This

Instead of modifying the original object directly, spread creates a new object while copying existing properties.

This pattern is heavily used in:

• React state management

• Redux

• Immutable data handling

Spread Operator in Function Calls

Spread can also unpack array elements while calling functions.

const dimensions = [1920, 1080];

function createCanvas(width, height) {
  console.log(`Canvas Size: \({width}x\){height}`);
}

createCanvas(...dimensions);

Output

Canvas Size: 1920x1080

Without spread:

createCanvas(dimensions);

The function would receive the entire array as a single argument.

Spread separates the values automatically.

What is the Rest Operator?

The rest operator collects multiple values and stores them inside a single variable.

It is mostly used in:

• Function parameters

• Array destructuring

• Object destructuring

A simple way to remember it:

Spread → Unpack
Rest → Pack

Rest Operator in Function Parameters

Sometimes you do not know how many arguments a function will receive.

The rest operator helps handle this situation elegantly.

function calculateTotal(...prices) {

  let total = 0;

  for (const price of prices) {
    total += price;
  }

  console.log(`Total Amount: ${total}`);
}

calculateTotal(120, 80, 150, 50);

Output

Total Amount: 400

What Happened Here?

...prices

collected all incoming arguments into one array:

[120, 80, 150, 50]

That means:

• prices becomes an array

• You can use array methods on it

• The function becomes flexible

Rest Operator in Array Destructuring

Rest is also useful while extracting values from arrays.

const serverLogs = [
  'Error 500',
  'Database Connected',
  'User Logged In',
  'Cache Cleared'
];

const [latestLog, ...olderLogs] = serverLogs;

console.log(latestLog);
console.log(olderLogs);

Output

Error 500

[
  'Database Connected',
  'User Logged In',
  'Cache Cleared'
]

Rest Operator with Objects

You can also separate properties from objects.

const laptop = {
  brand: 'HP',
  processor: 'Ryzen 7',
  ram: '16GB',
  gpu: 'RTX 3050'
};

const { brand, ...specifications } = laptop;

console.log(brand);
console.log(specifications);

Output

HP

{
  processor: 'Ryzen 7',
  ram: '16GB',
  gpu: 'RTX 3050'
}

Key Differences Between Spread and Rest

Real-World Example

Let’s combine both operators in one practical example.

const activeUser = {
  id: 101,
  name: 'Pallab'
};

const permissions = ['read', 'write', 'delete'];

function createSession(user, ...accessRights) {

  return {
    ...user,
    status: 'active',
    permissions: [...accessRights]
  };
}

const session = createSession(activeUser, ...permissions);

console.log(session);

Output

{
  id: 101,
  name: 'Pallab',
  status: 'active',
  permissions: ['read', 'write', 'delete']
}

Common Mistakes Developers Make

Mistake 1: Confusing Spread and Rest

function demo(...items) {}

This is Rest because it collects arguments.

const copied = [...array];

This is Spread because it expands values.

Mistake 2: Rest Must Be Last

This is invalid:

const [...remaining, last] = [1, 2, 3];

Rest elements must always appear at the end.

Correct version:

const [first, ...remaining] = [1, 2, 3];

When to Use Spread

Use spread when you want to:

• Merge arrays

• Copy arrays

• Clone objects

• Pass array items individually

• Create immutable updates

When to Use Rest

Use rest when you want to:

• Accept unlimited function arguments

• Collect remaining values

• Group leftover items

• Simplify destructuring

Final Thoughts

The triple-dot syntax becomes much easier once you focus on its behavior instead of the symbol itself.

Remember This Rule

Spread → Expands values
Rest → Collects values

At first glance, Node.js seems like it should fail under pressure. It runs JavaScript on a single thread, and common intuition suggests that a single-threaded system cannot handle multiple users efficiently. Yet Node.js is widely used to build systems that handle thousands of concurrent requests.

The reason lies in how Node.js is designed. It does not rely on multiple threads executing your application code in parallel. Instead, it uses an event-driven, non-blocking architecture where one main thread coordinates work while delegating heavy tasks elsewhere. This creates high concurrency without the overhead of traditional multi-threaded systems.

To truly understand Node.js, you need to understand three core ideas: the single-threaded model, the event loop, and delegation to background workers.

The Single-Threaded Nature of Node.js

Node.js executes JavaScript on a single main thread. This means only one piece of JavaScript runs at a time. There is no automatic multi-threading for your application logic.

If everything were written in a blocking way, this would be a serious limitation. For example:

const fs = require("fs");

const data = fs.readFileSync("file.txt", "utf-8");
console.log(data);

Here, the program stops completely until the file is read. During that time, no other request can be processed. This is blocking behavior, and if used heavily, it destroys performance.

However, Node.js is not meant to be used this way. Its real strength comes from non-blocking, asynchronous execution.

Introducing the Head Chef Analogy

To understand how Node.js handles concurrency, imagine a kitchen.

• There is one head chef

• There are multiple assistant chefs

• Orders keep coming in from customers

The head chef represents the main thread and event loop.
The assistant chefs represent background workers and system-level operations.

Now, here is the key rule:

The head chef does not cook slow dishes. The head chef coordinates.

How the Kitchen Handles Orders

Let’s walk through how this kitchen operates.

When an order arrives:

1. The head chef takes the order.

2. If the task is quick, the head chef handles it immediately.

3. If the task takes time (like baking or slow cooking), the head chef assigns it to an assistant chef.

4. The head chef immediately moves on to the next order.

The head chef never stands idle waiting for a dish to finish. That is the critical difference. When an assistant chef finishes a dish, they notify the head chef. The head chef then serves it. This continuous coordination is what allows one chef to manage many orders at once.

The Event Loop: The Head Chef’s Workflow

The event loop is the mechanism that keeps everything running.

It continuously does the following:

• Checks if there are tasks ready to execute

• Executes them one by one

• Picks up completed tasks from background workers

• Continues the cycle

In code, this looks like:

const fs = require("fs");

fs.readFile("file.txt", "utf-8", (err, data) => {
  console.log("File read complete");
});

console.log("This runs first");

Even though the file read is initiated first, the last line executes immediately. That is because Node.js delegates the file reading and continues execution.

The callback is executed later when the operation completes.

Delegating Work to Background Workers

Node.js does not perform heavy operations like file reading or network requests on the main thread. Instead, it delegates them to background workers managed by its internal system.

These workers handle tasks such as:

• File system operations

• Network requests

• Database queries

• Cryptographic functions

Once a task is delegated:

• Node.js registers a callback

• Moves on to handle other tasks

• Receives the result later

• Executes the callback via the event loop

This delegation ensures that the main thread is never blocked.

Concurrency vs Parallelism

It is important to distinguish between these two concepts.

Concurrency means multiple tasks are in progress at the same time.
Parallelism means multiple tasks are executing at the exact same time.

Node.js is primarily concurrent.

It does not execute multiple JavaScript tasks simultaneously on multiple cores by default. Instead, it efficiently manages many tasks without waiting.

Parallelism can be added using worker threads or clustering, but the core model focuses on concurrency.

Why Node.js Scales So Well

The design of Node.js leads to strong scalability.

First, it avoids creating a new thread for each request. Traditional servers often allocate one thread per client, which consumes memory and adds overhead. Node.js uses a single thread, so it remains lightweight.

Second, it minimizes context switching. Switching between threads is expensive. Node.js avoids this by staying on one thread.

Third, it is ideal for I/O-heavy workloads. Most applications spend time waiting for databases, files, or network responses. Node.js handles this waiting efficiently by not blocking.

Fourth, it simplifies development. Since there is only one main thread, developers avoid many common issues like race conditions and thread synchronization.

Real-World Example

Consider an API server that fetches user data.

Blocking approach:

const user = db.getUserSync(id);
res.send(user);

Each request blocks the server until the database responds.

Non-blocking Node.js approach:

db.getUser(id, (user) => {
  res.send(user);
});

Now, the server can handle many requests at once because it does not wait for each database call to complete.

Final Thoughts

Node.js does not scale because it does more work at the same time. It scales because it does not waste time waiting.

The single-threaded model is not a weakness. It is a design choice that works extremely well when combined with asynchronous execution and delegation.