Modern applications commonly use JWT (JSON Web Token) for this purpose because it is simple, scalable, and works very well with APIs.

In this article, we’ll understand what authentication means, what JWT is, how JWT authentication works in Node.js, and how protected routes use tokens for authorization.

What Authentication Means

Authentication is the process of verifying a user’s identity.

Example:

User enters:

• Email

• Password

The server checks whether the credentials are correct.

If valid:

User is authenticated

After authentication, the server must remember who the user is for future requests.

Why Authentication is Needed

Imagine a social media application.

Without authentication:

• anyone could access private accounts

• anyone could update user profiles

• anyone could delete posts

Authentication ensures that only verified users can access protected resources.

Traditional Authentication Problem

HTTP is stateless by default.

This means every request is treated independently.

Example:

GET /profile

The server does not automatically know who sent the request.

JWT solves this problem using token-based authentication.

What is JWT?

JWT stands for:

JSON Web Token

A JWT is a secure token used to identify authenticated users.

After login:

1. Server creates a token

2. Token is sent to the client

3. Client stores the token

4. Client sends token with future requests

5. Server verifies the token

JWT Authentication Flow

  User Login
      ↓
  Server Verifies Credentials
      ↓
  JWT Token Generated
      ↓
  Token Sent to Client
      ↓
  Client Stores Token
      ↓
  Client Sends Token in Requests
      ↓
  Server Verifies Token
      ↓
  Protected Data Returned

JWT is Stateless Authentication

JWT authentication is called stateless because the server usually does not store login session data.

Instead:

Token itself contains user information

This makes JWT systems scalable and API-friendly.

Structure of a JWT

A JWT contains three parts:

HEADER.PAYLOAD.SIGNATURE

Example:

eyJhbGciOi...
.
eyJpZCI6...
.
SflKxwRJS...

Each section has a specific purpose.

1. Header

The header contains metadata about the token.

Example:

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

It specifies:

• token type

• signing algorithm

2. Payload

The payload contains user-related data.

Example:

{
  "id": "123",
  "email": "user@example.com",
  "role": "user"
}

This information is called claims.

Important:

JWT payload is encoded, not encrypted.

Do not store:

• passwords

• sensitive secrets

• confidential information

3. Signature

The signature verifies that the token was not modified.

The server creates it using:

• header

• payload

• secret key

This ensures token integrity.

Login flow using JWT

Creating a JWT Token

Example:

import jwt from "jsonwebtoken";

const token = jwt.sign(
    {
        id: user._id,
        email: user.email
    },
    process.env.JWT_SECRET,
    {
        expiresIn: "7d"
    }
);

Understanding the Parameters

Payload :

{
    id: user._id,
    email: user.email
}

Data stored inside the token.

Secret Key :

process.env.JWT_SECRET

Used to sign and verify tokens.

Expiration Time :

expiresIn: "7d"

Defines how long the token remains valid.

Sending JWT to Client

After successful login:

res.json({
    token
});

The frontend stores the token.

Usually in:

• localStorage

• sessionStorage

• HTTP-only cookies

Sending Token with Requests

The client sends the token in request headers.

Example:

Authorization: Bearer jwt_token_here

This is the standard JWT authorization format.

Protecting Routes Using JWT

Protected routes require valid tokens.

Example middleware:

import jwt from 'jsonwebtoken'

const authMiddleware = (req, res, next) => {

    const authHeader = req.headers.authorization;

    if (!authHeader) {
        return res.status(401).json({
            message: "Token missing"
        });
    }

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

    try {

        const decoded = jwt.verify(
            token,
            process.env.JWT_SECRET
        );

        req.user = decoded;

        next();

    } catch (error) {

        return res.status(401).json({
            message: "Invalid token"
        });
    }
};

Using Protected Middleware

Example route:

app.get("/profile", authMiddleware, (req, res) => {

    res.json({
        message: "Protected profile",
        user: req.user
    });

});

Only authenticated users can access this route.

JWT Token Validation Lifecycle

  Client Sends JWT
        ↓
  Server Extracts Token
        ↓
  JWT Signature Verified
        ↓
  Payload Decoded
        ↓
  Access Granted

Conclusion

JWT authentication provides a modern and scalable way to handle user authentication in Node.js applications.

By understanding:

• how JWT works

• token structure

• login flow

• protected routes

• token verification

you can build secure authentication systems for modern applications.

JWT may seem complicated initially, but once you understand the token flow, it becomes one of the most practical and widely used authentication approaches in backend development.

Whenever you:

• fetch users

• create posts

• update profiles

• delete products

you are usually interacting with a REST API.

REST APIs are one of the most widely used ways to build backend services, and Express.js makes creating them simple and powerful.

In this article, we’ll understand what REST APIs are, how REST architecture works, HTTP methods, status codes, and how to design clean RESTful routes using Express.js.

What is a REST API?

REST stands for:

Representational State Transfer

A REST API is a structured way for clients and servers to communicate over HTTP.

The client sends requests, and the server sends responses.

Example:

Frontend App  →  REST API  →  Database

The API acts as a bridge between the frontend and backend.

Understanding APIs in Simple Words

An API is like a waiter in a restaurant.

Customer → Waiter → Kitchen

• Customer = Client

• Waiter = API

• Kitchen = Server/Database

The client requests data through the API, and the server processes and returns a response.

Resources in REST Architecture

REST APIs are built around resources.

A resource is simply a piece of data or an entity in the system.

Examples:

• users

• products

• posts

• orders

In REST, resources are usually represented using nouns.

Good examples:

/users
/products
/orders

Bad examples:

/getUsers
/createProduct
/deleteOrder

REST focuses on resources, not actions.

HTTP Methods in REST APIs

REST APIs use HTTP methods to define actions.

These methods map directly to CRUD operations.

GET Request

Used to fetch data.

Example:

GET /users

Express example:

app.get("/users", (req, res) => {
    res.send("Fetch all users");
});

Fetch a single user:

GET /users/1

POST Request

Used to create new data.

Example:

POST /users

Express example:

app.post("/users", (req, res) => {
    res.send("Create new user");
});

PUT Request

Used to update existing data.

Example:

PUT /users/1

Express example:

app.put("/users/:id", (req, res) => {
    res.send("Update user");
});

DELETE Request

Used to remove data.

Example:

DELETE /users/1

Express example:

app.delete("/users/:id", (req, res) => {
    res.send("Delete user");
});

REST Route Design Principles

REST APIs follow clean and predictable route naming conventions.

Use Nouns Instead of Verbs

Correct:

/users
/products

Incorrect:

/getUsers
/addProduct

The HTTP method already defines the action.

Use Plural Resource Names

Preferred:

/users
/posts
/orders

This makes APIs consistent and scalable.

Keep URLs Clean and Predictable

Good examples:

/users
/users/1
/users/1/posts

Avoid deeply nested complicated routes.

Example REST API for Users Resource

Here’s a clean RESTful design for users.

This structure becomes very intuitive once you follow REST principles consistently.

REST Request-Response Lifecycle

A REST API request typically follows this flow:

Client Request
      ↓
Express Route
      ↓
Business Logic
      ↓
Database Operation
      ↓
JSON Response

Status Codes Basics

HTTP status codes help clients understand the result of a request.

Common Success Codes

Example:

res.status(201).json({
    message: "User created"
});

Common Error Codes

Example:

res.status(404).json({
    message: "User not found"
});

Returning JSON Responses

REST APIs commonly return JSON data.

Example:

res.json({
    id: 1,
    name: "Rohit"
});

Typical response:

{
  "id": 1,
  "name": "Rohit"
}

Building a Simple REST API in Express

Example:

import express from 'express';

const app = express();

app.use(express.json());

let users = [];

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

app.post("/users", (req, res) => {
    users.push(req.body);

    res.status(201).json({
        message: "User created"
    });
});

app.listen(3000);

This demonstrates basic REST principles in action.

Conclusion

REST APIs provide a clean and standardized way for clients and servers to communicate.

By understanding:

• resources

• HTTP methods

• route design

• status codes

• request-response flow

you can build scalable and maintainable backend applications using Express.js.

Once you follow REST principles consistently, your APIs become easier to understand, easier to document, and much easier to scale in real-world applications.

This is where concepts like:

• Sessions

• Cookies

• JWT (JSON Web Tokens)

come into play.

Many beginners confuse these terms because they are often used together.
In reality, they solve different parts of the authentication process.

In this article, we’ll understand how sessions, cookies, and JWTs work, the difference between stateful and stateless authentication, and when each approach should be used in real-world applications.

Why Authentication is Needed

Imagine a user logs into a website.

After login, every future request should identify:

• who the user is

• whether they are authenticated

• what permissions they have

But HTTP is stateless by default.

That means every request is treated as completely new.

Authentication systems solve this problem by storing or sending user identity information between requests.

What are Cookies?

Cookies are small pieces of data stored in the browser.

The server sends cookies to the client, and the browser automatically sends them back with future requests.

Example response header:

Set-Cookie: sessionId=abc123

The browser stores it and sends it automatically:

Cookie: sessionId=abc123

Cookies themselves are not authentication systems.

They are simply a storage mechanism used to store:

• session IDs

• JWT tokens

• user preferences

• tracking information

What are Sessions?

A session is a server-side authentication mechanism.

In session-based authentication:

1. User logs in

2. Server creates a session

3. Session data is stored on the server

4. A session ID is sent to the browser through cookies

5. Browser sends the session ID with every request

6. Server verifies the session

Session Authentication Flow

User Login
    ↓
Server Creates Session
    ↓
Session Stored in Database/Memory
    ↓
Session ID Sent in Cookie
    ↓
Browser Stores Cookie
    ↓
Browser Sends Cookie in Future Requests
    ↓
Server Verifies Session

Example of Session-Based Authentication

After login :

req.session.user = {
    id: user._id,
    email: user.email
};

The server stores this session data.

The client only stores the session ID.

What are JWT Tokens?

JWT stands for JSON Web Token.

A JWT is a self-contained token that stores user information directly inside the token itself.

Unlike sessions, JWT authentication usually does not require storing session data on the server.

Example JWT structure:

HEADER.PAYLOAD.SIGNATURE

Example payload:

{
  "id": "123",
  "email": "user@example.com"
}

The token is signed by the server to prevent tampering.

JWT Authentication Flow

User Login
    ↓
Server Creates JWT
    ↓
JWT Sent to Client
    ↓
Client Stores Token
    ↓
Client Sends JWT in Requests
    ↓
Server Verifies JWT Signature
    ↓
Request Authorized

Example JWT Authentication

Generating token:

const token = jwt.sign(
    {
        id: user._id
    },
    process.env.JWT_SECRET,
    {
        expiresIn: "7d"
    }
);

Sending token:

res.json({
    token
});

Client sends token in headers:

Authorization: Bearer jwt_token_here

Stateful vs Stateless Authentication

This is the biggest conceptual difference.

Stateful Authentication

Sessions are stateful.

The server stores authentication data.

Example:

Server Memory / Database
    ↓
Session Data Stored

The server must remember every logged-in user.

Stateless Authentication

JWT is stateless.

The server does not store user login state.

The token itself contains the required information.

Example:

Client Holds Token
    ↓
Server Only Verifies Signature

This makes JWT systems easier to scale.

Sessions vs JWT Authentication

Here’s the core difference.

How Cookies Work with Sessions

Sessions usually depend on cookies.

Example:

Cookie:
sessionId=abc123

The cookie stores only the session ID.

The actual user data remains on the server.

How Cookies Work with JWT

JWTs can also be stored inside cookies.

Example :

Cookie:
token=jwt_token_here

Or stored in:

• localStorage

• sessionStorage

• memory

When to Use What

Session-Based Authentication

Sessions are great for:

• traditional server-rendered websites

• admin panels

• applications with tight server control

• systems requiring easy logout handling

Examples:

• banking portals

• dashboards

• CMS systems

Advantages:

• easy invalidation

• secure server-controlled sessions

• simpler browser integration

JWT Authentication

JWT works best for:

• REST APIs

• mobile apps

• microservices

• distributed systems

• frontend-backend separated architectures

Examples:

• React frontend + Node backend

• mobile applications

• third-party API authentication

Advantages:

• scalable

• lightweight server load

• cross-platform friendly

Conclusion

Sessions, cookies, and JWTs are all important parts of authentication systems, but they serve different purposes.

• Cookies are browser storage mechanisms

• Sessions store authentication state on the server

• JWT stores authentication data inside signed tokens

The biggest difference comes down to:

• stateful authentication (sessions)

• stateless authentication (JWT)

Neither approach is universally better.

Choosing the right authentication method depends on your application architecture, scalability needs, and development style.

Understanding these concepts clearly is essential for building secure and scalable backend applications.

Whether it’s logging requests, checking authentication, validating input, or handling errors, middleware sits in the middle of the request-response cycle and controls how requests move through your application.

In this article, we’ll understand what middleware is, how it works internally, different types of middleware, and why it plays such a critical role in Express applications.

What is Middleware in Express?

Middleware in Express is simply a function that runs between receiving a request and sending a response.

It gets access to:

• req → the incoming request

• res → the response object

• next() → a function that passes control to the next middleware

Basic syntax:

const middleware = (req, res, next) => {
    console.log("Middleware executed");

    next();
};

Middleware acts like a checkpoint in the request lifecycle.

Instead of sending every request directly to the route handler, Express allows middleware to inspect, modify, block, or process requests before they reach the final response.

Middleware in the Request Lifecycle

Here’s how a request typically flows in Express:

Client Request
      ↓
Middleware 1
      ↓
Middleware 2
      ↓
Middleware 3
      ↓
Route Handler
      ↓
Response Sent

Think of middleware as workers standing in a pipeline.

Each worker performs a task and then either:

• passes the request forward using next()

• stops the request and sends a response

Middleware Execution Flow

A middleware chain works sequentially.

Example:

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("Home Route");
});

When a request hits /, the output becomes:

First middleware
Second middleware

Then the route handler sends the final response.

Role of next() Function

The next() function is extremely important in Express middleware.

It tells Express:

“Move to the next middleware or route handler.”

Example:

const logger = (req, res, next) => {
    console.log(req.method, req.url);

    next();
};

Without calling next(), the request gets stuck and never reaches the next step.

Example of a blocked request:

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

Since next() is missing and no response is sent, the browser keeps loading forever.

Types of Middleware in Express

Express supports multiple types of middleware.

1. Application-Level Middleware

Application-level middleware is attached directly to the Express app using:

app.use()

Example:

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

This middleware runs for every request unless restricted to a specific path.

Example with path:

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

Now it only runs for routes starting with /admin.

2. Router-Level Middleware

Router-level middleware works specifically with Express routers.

Example:

const router = express.Router();

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

This middleware only affects routes inside that router.

Useful for:

• admin panels

• API modules

• authentication-protected sections

3. Built-in Middleware

Express already provides some middleware functions.

Example:

• JSON Middleware

app.use(express.json());

This parses incoming JSON request bodies.

Without it:

req.body

would be undefined.

• Static File Middleware

app.use(express.static("public"));

This serves static files like:

• images

• CSS

• JavaScript files

Execution Order of Middleware

Middleware executes in the exact order it is defined.

Example :

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

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

Output:

Middleware 1
Middleware 2

If the order changes, behavior changes too.

This is extremely important for things like:

• authentication

• body parsing

• logging

• validation

For example, body parsing middleware should run before validation middleware.

Real-World Middleware Examples

Middleware becomes powerful when used for common backend tasks.

Logging Middleware

Used to log request details.

Example:

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

Output:

GET /users
POST /login

This helps in debugging and monitoring traffic.

Authentication Middleware

Checks whether a user is authenticated.

Example :

const authMiddleware = (req, res, next) => {
    const token = req.headers.authorization;

    if (!token) {
        return res.status(401).json({
            message: "Unauthorized"
        });
    }

    next();
};

Protected route:

app.get("/profile", authMiddleware, (req, res) => {
    res.send("Protected Profile");
});

Request Validation Middleware

Validates incoming request data before processing.

Example:

const validateUser = (req, res, next) => {
    const { name, email } = req.body;

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

    next();
};

Route usage:

app.post("/users", validateUser, (req, res) => {
    res.send("User created");
});

Why Middleware is So Important

Middleware is the backbone of Express applications.

It allows developers to:

• separate logic cleanly

• reuse functionality

• create scalable APIs

• control request flow efficiently

Almost every major backend feature in Express is implemented using middleware.

Examples include:

• authentication

• file uploads

• request parsing

• CORS handling

• logging

• rate limiting

• error handling

Conclusion

Middleware is one of the most powerful concepts in Express.js.

It acts as a bridge between the incoming request and the final response, allowing you to process requests step by step.

By understanding:

• how middleware works

• execution order

• the role of next()

• different middleware types

you gain much better control over how your Express applications behave.

As your applications grow, middleware becomes essential for writing clean, organized, and maintainable backend code.

This is where URL parameters and query strings come into play.

At first, both may look similar because they pass data through the URL, but they serve completely different purposes. Understanding when to use each one is important for designing clean and professional APIs.

In this article, we’ll understand the difference between URL parameters and query strings in a simple and practical way using Express.js examples.

What URL Parameters Are ?

URL parameters, also called route parameters, are dynamic values written directly inside the URL path.

They are mainly used to identify a specific resource.

For example:

/users/25

Here:

• users represents the route

• 25 represents a specific user ID

In this case, 25 is a URL parameter.

Think of URL parameters as identifiers.

Examples:

• user ID

• product ID

• blog slug

• order ID

Example routes:

/products/101
/blog/react-hooks-guide
/orders/9001

Each URL points to one specific resource.

Accessing params in Express

In Express, route parameters are accessed using:

req.params

Example:

import express from "express";

const app = express();

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

  const userId = req.params.id;

  res.send(`User ID is ${userId}`);

});

app.listen(3000);

If the user visits:

http://localhost:3000/users/25

Response:

User ID is 25

The :id part is called a route parameter placeholder.

Express automatically extracts the value and stores it inside req.params.

You can also use multiple parameters:

app.get("/users/:userId/posts/:postId", (req, res) => {

  res.json(req.params);

});

URL:

/users/25/posts/100

Response:

{
  "userId": "25",
  "postId": "100"
}

What query parameters are

Query parameters, also called query strings, are extra values added after a ? in the URL.

They are usually used for:

• filtering

• sorting

• searching

• pagination

• modifying results

Example:

/products?category=mobile

Here:

• /products is the main route

• category=mobile is a query parameter

Unlike route parameters, query strings do not identify a specific resource.

Instead, they modify the response.

Think of query parameters as filters or modifiers.

Accessing query strings in Express

In Express, query parameters are accessed using:

req.query

Example:

import express from "express";

const app = express();

app.get("/products", (req, res) => {

  const category = req.query.category;

  res.send(`Category is ${category}`);

});

app.listen(3000);

URL:

http://localhost:3000/products?category=mobile

Response:

Category is mobile

Multiple query parameters can also be used:

/products?category=mobile&sort=price&page=2

Express converts them into an object:

{
  category: "mobile",
  sort: "price",
  page: "2"
}

Differences between them

Although both are passed through the URL, their purpose is completely different.

Understanding with practical examples

Example 1: User profile ID

/users/25

Here:

• 25 identifies a specific user

• URL parameter should be used

Express route:

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

  const id = req.params.id;

  res.send(`Fetching user ${id}`);

});

Example 2: Search filters

/products?category=mobile&brand=samsung

Here:

• we are filtering products

• query strings should be used

Express route:

app.get("/products", (req, res) => {

  const { category, brand } = req.query;

  res.json({
    category,
    brand
  });

});

URL structure breakdown

Example URL:

/users/25/orders?status=completed&page=1

Breakdown:

/users           → route
25               → URL parameter
/orders          → nested route
status=completed → query parameter
page=1           → query parameter

This clearly shows how both params and query strings can exist together in the same URL.

When To Use Params vs Query

A simple rule developers commonly follow:

Use URL parameters when:

• identifying a specific resource

• fetching one item

• route structure depends on value

Examples:

• /users/10

• /products/55

• /posts/react-guide

Use query strings when:

• filtering data

• sorting results

• searching

• pagination

• optional modifiers

Examples:

• /products?category=laptop

• /users?page=2

• /search?keyword=nodejs

Params vs query comparison diagram

URL Parameter Example:
--------------------------------
/users/25
       ↑
    Specific Resource ID


Query Parameter Example:
--------------------------------
/users?age=25&city=Delhi
      ↑
   Filters / Modifiers

Conclusion

URL parameters and query strings may look similar, but they solve different problems in web applications. Route parameters are mainly used for identifying specific resources, while query strings are used for filtering, searching, sorting, or modifying results.

Understanding this difference helps you design cleaner APIs and makes your routes easier to understand and maintain. A good Express application uses both properly depending on the purpose of the request.

Once you become comfortable with params and query strings, building dynamic routes and flexible APIs in Express.js becomes much more intuitive.

In Express applications, handling uploads is not as straightforward as handling normal JSON data. Files are sent differently by the browser, which is why we need specialized middleware like Multer.

In this article, we’ll understand how file uploads work in Express using Multer, how to upload single and multiple files, and how uploaded files are eventually served to users.

Why file uploads need middleware

When we send normal form data, Express can easily read it using middleware like:

app.use(express.json());

But file uploads work differently.

Files are usually sent using a format called:

multipart/form-data

This format contains:

• file data

• form fields

• metadata

Unlike JSON, Express cannot parse multipart data by default.

That’s why file upload middleware is required.

Without middleware:

• req.body may work for text fields

• uploaded files will not be processed correctly

This is where Multer helps.

What Multer is ?

Multer is a middleware for Express that handles multipart/form-data.

Its main job is to:

• receive uploaded files

• process them

• store them on the server

• provide file information inside the request object

Install Multer:

npm install multer

Basic Setup :

import express from "express";
import multer from "multer";

const app = express();

const upload = multer({
  dest: "uploads/"
});

Here :

• Multer stores uploaded files inside the uploads folder

• file information becomes available in the request

Understanding the upload lifecycle

Here’s what happens behind the scenes during a file upload:

Client Selects File
        ↓
Browser Sends multipart/form-data Request
        ↓
Multer Middleware Receives File
        ↓
Multer Processes File
        ↓
File Stored in uploads Folder
        ↓
Request Continues to Route Handler

Multer acts like a middle layer between the incoming request and your route handler.

Handling single file upload

Single file uploads are commonly used for:

• profile pictures

• thumbnails

• resumes

• documents

Example:

import express from "express";
import multer from "multer";

const app = express();

const upload = multer({
  dest: "uploads/"
});

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

  res.json({
    message: "File uploaded successfully",
    file: req.file
  });

});

app.listen(3000);

Important part:

upload.single("image")

This means:

• only one file is expected

• the input field name must be image

Example frontend form:

<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" is very important. Without it, files will not be sent properly.

After upload:

• file details are available inside req.file

• Multer automatically stores the file

Handling multiple file uploads

Sometimes users need to upload multiple files together.

Examples:

• product gallery images

• project documents

• media uploads

Multer provides:

upload.array()

Example:

import express from "express";
import multer from "multer";

const app = express();

const upload = multer({
  dest: "uploads/"
});

app.post("/uploads", upload.array("images", 5), (req, res) => {

  res.json({
    message: "Files uploaded successfully",
    files: req.files
  });

});

Here:

upload.array("images", 5)

means:

• field name is images

• maximum 5 files allowed

Frontend example:

<form action="/uploads" method="POST" enctype="multipart/form-data">

  <input type="file" name="images" multiple />

  <button type="submit">
    Upload Files
  </button>

</form>

Uploaded file details are available in:

req.files

Storage configuration basics

By default, Multer generates random file names.

But in real applications, developers usually configure storage manually.

Example:

const storage = multer.diskStorage({

  destination: (req, file, cb) => {
    cb(null, "uploads/");
  },

  filename: (req, file, cb) => {

    const uniqueName =
      Date.now() + "-" + file.originalname;

    cb(null, uniqueName);
  }

});

const upload = multer({ storage });

This configuration helps:

• organize uploaded files

• avoid duplicate file names

• generate readable file names

Example generated file:

174689223-profile.png

Minimal folder structure:

project/
│
├── uploads/
├── server.js
└── package.json

Keeping the structure simple makes uploads easier to understand for beginners.

Serving uploaded files

Uploading files is only part of the process. Users also need access to those uploaded files.

Express provides static middleware for this.

Example:

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

This line tells Express:

“Everything inside the uploads folder can be accessed publicly.”

Suppose the folder contains:

uploads/
└── profile.png

The file becomes accessible at:

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

This URL can be used:

• inside <img> tags

• in frontend applications

• for downloads

• in mobile apps

Complete example:

import express from "express";
import multer from "multer";

const app = express();

const storage = multer.diskStorage({

  destination: (req, file, cb) => {
    cb(null, "uploads/");
  },

  filename: (req, file, cb) => {

    const uniqueName =
      Date.now() + "-" + file.originalname;

    cb(null, uniqueName);
  }

});

const upload = multer({ storage });

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

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

  const fileUrl =
    `\({req.protocol}://\){req.get("host")}/uploads/${req.file.filename}`;

  res.json({
    message: "Upload successful",
    url: fileUrl
  });

});

app.listen(3000);

Multer middleware execution flow

Here’s the complete execution flow:

User Selects File
        ↓
Browser Sends multipart/form-data Request
        ↓
Multer Middleware Executes
        ↓
File Saved in uploads Folder
        ↓
req.file or req.files Created
        ↓
Route Handler Executes
        ↓
Response Sent to Client

Understanding this flow makes it much easier to debug upload-related issues in Express applications.

Conclusion

File uploads may look simple from the frontend, but a lot happens behind the scenes on the server. Since Express cannot process multipart file data on its own, middleware like Multer becomes essential for handling uploads properly.

Once you understand how Multer receives files, stores them, and passes file information to route handlers, building features like profile image uploads, document systems, or media galleries becomes much easier. Starting with local storage is the best way to learn the complete upload flow before moving toward advanced solutions like cloud storage or CDN-based systems later.

In Express applications, file handling usually involves two important parts:

• storing uploaded files

• making those files accessible through URLs

Let’s understand how this works behind the scenes.

Where uploaded files are stored

When a user uploads a file, the backend receives it as binary data. Your server then decides where that file should be stored.

In most beginner-level Express applications, uploaded files are stored inside a folder on the server itself. This is commonly called local storage.

Example folder structure:

 project/
 │
 ├── uploads/
 │   ├── image1.png
 │   ├── resume.pdf
 │   └── profile.jpg
 │
 ├── server.js
 └── package.json

The uploads folder contains all uploaded files.

Most developers use Multer middleware for handling file uploads in Express.

Example:

import express from "express";
import multer from "multer";

const app = express();

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

  filename: (req, file, cb) => {
    const uniqueName = Date.now() + "-" + file.originalname;
    cb(null, uniqueName);
  }
});

const upload = multer({ storage });

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

  res.json({
    message: "File uploaded successfully",
    file: req.file
  });

});

app.listen(3000);

In this example:

• files are stored inside the uploads folder

• every file gets a unique name

• req.file contains uploaded file information

Adding unique names is important because multiple users may upload files with the same name.

For example:

profile.png

Without unique naming, newer uploads may overwrite older files.

Local storage vs external storage concept

Local storage works well for:

• small applications

• learning projects

• development environments

But as applications grow, storing files directly on the server becomes difficult to manage.

That’s where external storage comes in.

Instead of storing files locally, the backend uploads files to cloud services such as:

• Amazon Web Services S3

• Cloudinary

• Firebase Storage

• Google Cloud Storage

The overall flow looks like this:

  User Uploads File
          ↓
  Express Server Receives File
          ↓
  File Uploaded to Cloud Storage
          ↓
  Cloud Service Returns URL
          ↓
  URL Stored in Database

Here’s a simple comparison:

For small apps, local storage is perfectly fine. But production-level applications usually prefer external storage because it is more scalable and reliable.

Serving static files in Express

Uploading files is only half the process. Users also need a way to access those files in the browser.

Express provides built-in middleware for serving static files.

Example:

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

This line tells Express:

“Everything inside the uploads folder can be accessed publicly.”

Suppose your folder contains:

uploads/
└── photo.png

Now the file becomes accessible at:

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

This is called static file serving.

Static files are files that do not require backend processing before being sent to the client.

Examples include:

• images

• videos

• PDFs

• CSS files

• JavaScript files

Express simply reads the file and sends it directly to the browser.

A complete example:

import express from "express";
import multer from "multer";

const app = express();

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

  filename: (req, file, cb) => {
    const uniqueName = Date.now() + "-" + file.originalname;
    cb(null, uniqueName);
  }
});

const upload = multer({ storage });

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

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

  res.json({
    message: "File uploaded successfully",
    file: req.file
  });

});

app.listen(3000);

Accessing uploaded files via URL

Once static serving is enabled, uploaded files can be accessed directly using URLs.

For example:

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

This URL can be used:

• inside <img> tags

• for file downloads

• in frontend applications

• inside mobile apps

Developers often generate file URLs dynamically after upload.

Example:

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

  const fileUrl =
    `\({req.protocol}://\){req.get("host")}/uploads/${req.file.filename}`;

  res.json({
    message: "Upload successful",
    url: fileUrl
  });

});

Response:

{
  "message": "Upload successful",
  "url": "http://localhost:3000/uploads/1746892-image.png"
}

Now the frontend can directly display the uploaded image:

<img src="FILE_URL" />

This is how profile pictures, product images, and downloadable documents are usually displayed in web applications.

Security considerations for uploads

File uploads can become dangerous if not handled properly. A malicious user may try to upload harmful files or overload the server.

That’s why upload security is extremely important.

Restrict file types

Only allow specific file formats.

Example:

const fileFilter = (req, file, cb) => {

  const allowedTypes = ["image/png", "image/jpeg"];

  if (allowedTypes.includes(file.mimetype)) {
    cb(null, true);
  } else {
    cb(new Error("Invalid file type"), false);
  }

};

const upload = multer({
  storage,
  fileFilter
});

This prevents unsupported or dangerous file types from being uploaded.

Limit file size

Large files can slow down or crash the server.

Example:

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

This limits uploads to 5MB.

Never trust original file names

Users can upload suspicious file names like:

../../../hack.js

Always rename files before storing them.

Keep sensitive files private

Not every uploaded file should be publicly accessible.

Examples:

• identity documents

• invoices

• medical reports

Such files should:

• stay outside public folders

• require authentication before access

Organize uploads properly

A clean folder structure helps maintain files easily.

Example:

uploads/
│
├── profiles/
├── products/
└── documents/

This makes file management much easier as the application grows.

Conclucsion

Handling file uploads in Express is not just about saving files to a folder. A proper upload system should also organize files correctly, make them accessible through URLs, and protect the server from unsafe uploads.

For small projects or learning purposes, local storage is usually enough and very easy to implement. But as applications grow and start handling large numbers of users or media files, external storage solutions become a much better option because they offer better scalability, reliability, and performance.

Once you understand how uploading, storage, static serving, and security work together, building features like profile image uploads, document sharing systems, galleries, or media platforms becomes much more manageable and professional.

Even simple tasks like:

• handling routes

• managing requests

• sending responses

• parsing data

require a lot of manual code.

That’s exactly why:

Express.js

became so popular.

Express is a lightweight web framework built on top of Node.js that makes backend development much simpler, cleaner, and faster.

In this article, we’ll understand what Express.js is, why developers use it, and how to create routes and handle requests using Express.

What Express.js Is ?

Express.js is a minimal and flexible web framework for Node.js.

It helps developers build:

• APIs

• web servers

• backend applications

• REST services

without writing repetitive low-level server code again and again.

Think of Node.js as the engine of a car.

Express.js is like the steering wheel, dashboard, and controls that make driving easier.

Node.js provides the core functionality, while Express provides a cleaner and more developer-friendly way to work with servers and routes.

Why Express Simplifies Node.js Development

To understand why Express became popular, let’s compare it with a raw Node.js HTTP server.

Raw Node.js HTTP Server

Here’s a simple server using Node.js only :

import http from 'http';

const server = http.createServer((req, res) => {

  if (req.url === "/") {
    res.send("Home Page");
  }

  else if (req.url === "/about") {
    res.send("About Page");
  }

});

server.listen(3000);

This works, but as the application grows:

• routing becomes messy

• request handling becomes repetitive

• middleware becomes difficult

• code organization suffers

Now compare that with Express.

Express Server Example

import express from 'express';

const app = express();

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

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

app.listen(3000);

The difference is immediately noticeable.

The code is:

• shorter

• cleaner

• easier to read

• easier to scale

That simplicity is one of the biggest reasons developers love Express.

Creating First Express Server

Now let’s create a basic Express server step-by-step.

Create a file called:

app.js

Then add this code:

import express from 'express';

const app = express();

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

Here’s what’s happening:

• express() creates an Express application

• app.listen() starts the server

• port 3000 becomes active

Run the file using:

node app.js

Understanding Routes in Express

A route is simply a path that the server responds to.

For example:

• /

• /about

• /contact

Different routes usually return different data or pages.

Express makes routing extremely simple using methods like:

• app.get()

• app.post()

• app.put()

• app.delete()

Each route contains:

1. a URL path

2. a request handler function

Handling GET Requests

GET requests are mainly used to retrieve data from the server.

Here’s a simple example:

import express from 'express';

const app = express();

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

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

app.listen(3000);

Now:

• visiting / returns "Welcome to Express"

• visiting /about returns "About Page"

Express automatically checks the route and runs the correct handler.

Request → Route Handler → Response Flow

  Browser Request
         ↓
  Express Route Matches URL
         ↓
  Route Handler Executes
         ↓
  Response Sent Back

This request-response cycle is the foundation of almost every backend application.

Handling POST Requests

POST requests are used when the client wants to send data to the server.

Examples include:

• login forms

• registration forms

• creating new records

• submitting data

Here’s a basic POST route:

app.post("/login", (req, res) => {
  res.send("Login Successful");
});

When a POST request hits /login, Express executes the route handler and sends a response back.

Even though this example is simple, the same concept is used in real-world authentication systems and APIs.

Sending Responses in Express

Express provides several ways to send responses.

The most common one is:

res.send()

It can send:

• text

• HTML

• JSON

• objects

Example:

res.send("Hello World");

You can also send JSON responses:

res.json({
  success: true,
  message: "Data fetched successfully"
});

This is especially useful when building APIs.

Express Routing Structure Visualization

  
  Incoming Request
         ↓
  Express Server
         ↓
  Route Matching
         ↓
  Correct Route Handler
         ↓
  Response Returned

As applications grow larger, Express allows routes to be organized into separate files and modules, making backend code much easier to maintain.

Why Developers Prefer Express

Express became the standard framework for Node.js because it removes a lot of complexity from backend development.

Instead of manually handling low-level server logic, developers can focus more on building application features.

It offers:

• clean routing

• middleware support

• easier request handling

• faster API development

• scalable project structure

At the same time, Express stays lightweight and flexible, which is why it remains one of the most widely used Node.js frameworks today.

Conclusion

Express.js simplified backend development for Node.js developers in a huge way.

Instead of writing repetitive server code manually, developers can define routes and handle requests using clean, readable syntax.

The most important thing to understand is this:

A route listens for a request and sends back a response.

That simple request-response cycle powers almost every web application and API on the internet.

And Express makes working with that cycle incredibly easy.

That’s one of the main reasons Node.js became so popular.

Node.js introduced a different way of handling requests compared to many traditional backend technologies. Instead of creating heavy thread-based systems, Node.js focused on lightweight, event-driven, asynchronous processing.

The result was a runtime that could handle large numbers of concurrent connections with impressive efficiency.

In this article, we’ll understand what makes Node.js fast, how its architecture works, and why so many companies adopted it for modern web applications.

What Makes Node.js Fast

One of the biggest reasons Node.js feels fast is that it avoids wasting time waiting.

Traditional backend servers often process requests in a blocking way. A request arrives, the server starts processing it, and if the server needs data from a database or file system, it waits until the operation finishes before moving to the next task.

That waiting time becomes expensive when thousands of users connect simultaneously.

Node.js approaches the problem differently.

Instead of blocking while waiting for slow operations, Node.js delegates those tasks and immediately continues handling other requests. This keeps the server productive almost all the time.

Another important reason behind Node.js performance is the:

V8

V8 compiles JavaScript into highly optimized machine code, making execution extremely fast. Combined with Node.js’s lightweight architecture, this creates a very efficient runtime for web applications.

Understanding Non-Blocking I/O

To understand why Node.js performs so well, you first need to understand the idea of non-blocking I/O.

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

• database queries

• file reading

• API calls

• network communication

These operations usually take time.

In a blocking system, the server waits until the operation finishes.

In a non-blocking system like Node.js, the server starts the operation and immediately moves on to handle something else.

Imagine a restaurant chef.

A blocking chef takes one order and stands beside the stove waiting for the food to cook before accepting another order.

A smart chef works differently. They place the food on the stove, set a timer, and immediately start preparing the next order while the previous one cooks.

That’s exactly how Node.js handles asynchronous operations.

Instead of waiting, it keeps moving.

Blocking vs Non-Blocking Request Handling

Here’s the difference visually.

Traditional Blocking Server :

Request 1 → Processing → Waiting → Response
Request 2 → Must Wait
Request 3 → Must Wait

If one request takes too long, other requests get delayed behind it.

Node.js Non-Blocking Server :

Request 1 → Async Task Started
Request 2 → Processing
Request 3 → Processing
       ↓
Completed Tasks Return Later

Node.js keeps accepting and processing new requests while previous operations continue in the background.

This is one of the core reasons it scales so efficiently.

Event-Driven Architecture

Another major strength of Node.js is its event-driven architecture.

Instead of continuously checking whether tasks are complete, Node.js listens for events.

For example:

• database query completed

• file read finished

• API response received

• user connected

When an event occurs, Node.js triggers the associated callback or handler.

This architecture works extremely well for applications involving lots of simultaneous activity because the server spends very little time sitting idle.

At the center of this system is the Event Loop, which continuously manages incoming requests, async operations, and completed tasks.

Understanding the Single-Threaded Model

One thing that surprises many developers is that Node.js is single-threaded for JavaScript execution.

At first, this sounds like a weakness.

People naturally ask:

“How can one thread handle thousands of users?”

The answer is that Node.js focuses on concurrency, not direct parallelism.

Concurrency means handling multiple tasks efficiently without blocking. Parallelism means multiple tasks literally running at the same exact time on multiple CPU cores.

Node.js achieves excellent concurrency by using:

• non-blocking operations

• async execution

• event-driven processing

The single thread mostly coordinates tasks instead of waiting for them.

That’s why Node.js can manage thousands of active connections without creating thousands of heavy threads.

Event Loop Request Processing Visualization

  Incoming Requests
         ↓
  Event Loop Receives Tasks
         ↓
  Async Operations Delegated
         ↓
  Event Loop Continues Handling Requests
         ↓
  Completed Tasks Return
         ↓
  Responses Sent Back

This continuous flow is what allows Node.js servers to remain responsive even under heavy traffic.

Where Node.js Performs Best

Node.js performs exceptionally well for applications that involve many simultaneous connections and lots of I/O operations.

It shines in scenarios like:

• REST APIs

• real-time chat systems

• streaming platforms

• live dashboards

• multiplayer games

• collaboration tools

• notification systems

These applications spend most of their time waiting for external operations like databases or APIs rather than performing extremely heavy CPU calculations.

That makes them a perfect fit for Node.js’s asynchronous architecture.

Real-World Companies Using Node.js

Many large companies adopted Node.js because of its scalability and real-time capabilities.

Popular companies that have used Node.js include:

• Netflix

• LinkedIn

• Uber

• PayPal

• Walmart

These companies needed systems capable of handling huge numbers of concurrent users efficiently, and Node.js proved to be a strong fit for those requirements.

Why Developers Love Node.js

Performance is only part of the reason developers love Node.js.

Another huge advantage is that developers can use JavaScript on both:

• frontend

• backend

This simplifies development workflows and allows teams to share knowledge more easily.

The npm ecosystem also accelerated Node.js adoption by giving developers access to thousands of reusable packages and tools.

Combined with its fast development experience and scalable architecture, Node.js became one of the most important technologies in modern web development.

Conclusion

Node.js became popular because it solved a very important problem:

How do you handle large numbers of users efficiently without wasting resources?

Its non-blocking I/O model, event-driven architecture, and lightweight concurrency system made it perfect for modern web applications that rely heavily on real-time communication and asynchronous operations.

The key idea behind Node.js performance is simple:

Don’t wait. Keep processing other work.

And that simple idea is exactly what makes Node.js so powerful for building fast, scalable web applications.

In this article, we’ll go step-by-step through the complete setup process. You’ll learn how to install Node.js, verify the installation, understand the Node REPL, create your first JavaScript file, and finally build a simple “Hello World” server.

The goal here is not to build a complex project, but to understand how Node.js actually runs JavaScript outside the browser.

Installing Node.js

The first step is installing Node.js on your system.

When you install Node.js, two important things get installed:

• the Node.js runtime

• npm (Node Package Manager)

npm helps developers install libraries and tools later, but for now we’ll focus mainly on Node.js itself.

To install Node.js, go to: Node.js Official Website

You’ll usually see two versions:

• LTS (Long Term Support) → stable and recommended for most users

• Current → latest features but less stable

For beginners, the LTS version is the safest choice.

The installation process is mostly straightforward regardless of whether you use Windows, macOS, or Linux. Download the installer, follow the setup instructions, and Node.js will be added to your system.

Checking the Installation Using Terminal

After installation, it’s important to confirm that Node.js is working correctly.

Open your terminal or command prompt and type:

node -v

If Node.js is installed properly, you’ll see something like:

v22.5.1

This command simply shows the installed Node.js version.

You can also check npm using:

npm -v

This confirms that the Node Package Manager was installed successfully as well.

At this point, your system is ready to run JavaScript outside the browser.

Understanding the Node REPL

Before creating files, it’s useful to understand something called the Node REPL.

REPL stands for:

• Read

• Evaluate

• Print

• Loop

It’s basically an interactive Node.js environment where you can write JavaScript directly in the terminal and instantly see the result.

To start the REPL, simply type:

node

You’ll enter an interactive mode that looks something like this:

>

Now you can write JavaScript directly.

Example :

> 2 + 3

> 5  // output

You can also test variables and functions:

const name = "Rohit";

console.log(name);

The REPL is extremely useful for quick testing and experimentation because you don’t need to create separate files every time.

To exit the REPL press ctrl + c twice, or type:

.exit

Creating Your First JavaScript File

Now let’s create an actual Node.js program.

Create a new folder anywhere on your computer. Inside that folder, create a file called:

app.js

Open the file in your code editor and write:

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

This is your very first Node.js application.

Even though the code looks simple, something important is happening here:

JavaScript is now running outside the browser.

There’s no HTML page, no browser console, and no frontend UI involved.

Node.js is directly executing the JavaScript file on your system.

Running the Script Using the Node Command

To execute the file, open the terminal inside your project folder and run:

node app.js

You should see:

Hello from Node.js

This is the basic Node.js execution flow:

  JavaScript File
         ↓
  Node.js Runtime
         ↓
  Execution
         ↓
  Terminal Output

The node command tells the Node.js runtime to execute the specified JavaScript file.

This is the foundation of every Node.js application.

Writing Your First Hello World Server

Printing text is useful for understanding execution, but one of the biggest reasons developers use Node.js is to create servers.

Now let’s build a simple web server.

Replace the contents of app.js with this code:

import http from 'http';

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

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

At first, this code may look unfamiliar, but the idea is simple.

We are:

1. importing Node’s built-in HTTP module

2. creating a server

3. sending a response

4. starting the server on port 3000

Now run the file again:

node app.js

You’ll see:

Server running on port 3000

Open your browser and visit:

http://localhost:3000

You’ll see:

Hello World from Node.js

And just like that, you created your first backend server using Node.js.

Understanding What Happened

When the browser visited localhost:3000, it sent a request to your Node.js server.

The server received the request, processed it, and sent back a response containing:

Hello World from Node.js

This is the same basic idea behind APIs and backend applications. Real-world applications become much more complex, but the core request-response cycle remains the same.

Node.js Execution Flow

Here’s a simplified flow of what happens internally:

  Browser Request
         ↓
  Node.js Server
         ↓
  Request Handler Executes
         ↓
  Response Sent Back
         ↓
  Browser Displays Result

Understanding this flow is extremely important because nearly every backend application works using this same principle.

Conclusion

Setting up your first Node.js application is an important milestone because it introduces the core idea behind Node.js:

JavaScript can run outside the browser.

In this article, you learned how to:

• install Node.js

• verify the installation

• use the Node REPL

• execute JavaScript files

• create your first server

More importantly, you saw how Node.js takes a JavaScript file, executes it through the runtime, and turns it into a working backend application.

And that’s where the real Node.js journey begins.

But today, JavaScript is everywhere. Developers use it to build APIs, backend servers, chat applications, streaming platforms, and even desktop apps. A huge reason behind this transformation is Node.js.

Node.js completely changed how developers looked at JavaScript by allowing it to run outside the browser.

What Actually Node.js Is ?

Node.js is a runtime environment that allows JavaScript to run on servers and computers outside the browser.

That definition sounds technical at first, but the idea is actually simple.

JavaScript itself is just a programming language. Like any language, it needs an environment where it can execute. Inside a browser like Chrome or Firefox, the browser provides that environment. It gives JavaScript access to things like buttons, forms, the DOM, and browser APIs.

Node.js provides a different environment. Instead of focusing on webpages and browser interactions, Node.js gives JavaScript access to server-side features like:

• file systems

• databases

• networking

• operating system functionality

This means JavaScript can now create web servers, handle APIs, read files, and manage backend logic — things that were previously impossible using browser JavaScript alone.

Why JavaScript Was Originally Browser-Only

When JavaScript was created in 1995, its purpose was very different from what we use it for today. Websites at that time were mostly static. JavaScript was introduced to make webpages interactive without constantly reloading the page.

For example, clicking a button could instantly update content on the screen. Forms could validate user input before submission. Small interactive experiences became possible directly inside the browser.

Because of this, JavaScript became tightly connected to frontend development. Backend development remained in the hands of technologies like PHP and Java, which handled databases, authentication, and server-side logic.

For years, developers lived in a world where frontend and backend were completely separate ecosystems.

How Node.js Made JavaScript Run on Servers

Everything changed in 2009 when Ryan Dahl introduced Node.js.

The idea behind Node.js was surprisingly powerful:

What if JavaScript could run outside the browser?

Instead of limiting JavaScript to frontend interactions, Node.js allowed developers to execute JavaScript directly on servers. This meant developers could finally use the same language for both frontend and backend development.

Before Node.js, a developer might write JavaScript for the frontend and PHP or Java for the backend. Switching between different languages and ecosystems added complexity to development.

Node.js simplified that workflow dramatically. Suddenly, full-stack JavaScript development became possible, and developers loved the idea of using one language across the entire application.

JavaScript Language vs Runtime Environment

One thing that often confuses beginners is the difference between JavaScript itself and Node.js.

JavaScript is the language. Node.js is the runtime environment that executes that language outside the browser.

A simple analogy is to think of JavaScript as a recipe and the runtime as the kitchen where the recipe gets prepared. The recipe alone cannot produce food without a kitchen and tools.

Similarly, JavaScript code cannot execute by itself. It needs an environment.

Browsers provide one environment focused on webpages and UI interactions. Node.js provides another environment focused on backend and server functionality.

The language is the same, but the capabilities differ depending on where the code runs.

Browser JavaScript vs Node.js

A good way to understand Node.js is by comparing browser JavaScript with server-side JavaScript.

Inside the browser, JavaScript usually reacts to user interactions.

button.addEventListener("click", () => {
  alert("Button clicked!");
});

This code interacts with webpage elements and browser APIs.

Now compare that with Node.js:

import http from 'node:http';

http.createServer((req, res) => {
  res.end("Hello from Node.js");
}).listen(3000);

This code creates an actual web server.

That’s the biggest shift Node.js introduced. JavaScript was no longer limited to webpages, it became capable of running entire backend applications.

V8 Engine Overview

Under the hood, Node.js uses the:

V8

V8 is the same JavaScript engine originally built for Google Chrome. Its job is to take JavaScript code and convert it into machine code that the computer can execute efficiently.

Node.js uses V8 outside the browser environment, which is what allows JavaScript to run on servers.

You don’t need to understand deep engine internals to work with Node.js. The important thing is simply this:

V8 makes JavaScript execution fast.

And Node.js uses that speed to build scalable applications.

Event-Driven Architecture in Node.js

One of the biggest reasons developers adopted Node.js so quickly was its event-driven architecture.

Traditional backend systems often used a thread-based approach where each request occupied its own thread. As traffic increased, memory usage and server overhead increased as well.

Node.js approached the problem differently.

Instead of waiting for slow operations like database queries or file reads to finish, Node.js delegates those tasks and keeps processing other requests. This non-blocking model allows Node.js to handle many simultaneous connections efficiently without creating large numbers of threads.

That architecture made Node.js especially attractive for applications involving:

• real-time communication

• streaming

• APIs

• live dashboards

• chat systems

The server remains responsive because it spends very little time sitting idle waiting for operations to complete.

Why Developers Adopted Node.js

Node.js became popular not just because it was fast, but because it improved the overall developer experience.

Using JavaScript on both frontend and backend simplified development workflows. Teams could share knowledge, reuse logic, and work more consistently across projects.

At the same time, Node.js performed extremely well for I/O-heavy applications where servers spend most of their time waiting for external operations like databases or APIs.

Its package ecosystem through npm also played a massive role in its growth. Developers suddenly had access to thousands of reusable packages that accelerated development dramatically.

Real-World Use Cases of Node.js

Today, Node.js powers a huge number of modern applications. It is commonly used for building APIs, real-time chat systems, streaming platforms, collaboration tools, multiplayer games, and microservices.

Its event-driven architecture makes it particularly effective for applications where many users stay connected simultaneously.

That’s why Node.js became one of the most important technologies in modern web development.

Conclusion

Node.js changed the role of JavaScript completely.

What began as a browser scripting language evolved into a powerful backend technology capable of running scalable server applications.

The most important thing to remember is this:

Node.js is not a programming language.
It is a runtime environment that allows JavaScript to run outside the browser.

By combining JavaScript with the speed of the V8 engine and an event-driven architecture, Node.js made full-stack JavaScript development possible and transformed modern backend development forever.

At first, async programming can feel confusing because the code doesn’t always execute from top to bottom in a simple sequence. But once you understand why async code exists, callbacks and promises start making a lot more sense.

In this article, we’ll understand how asynchronous code works in Node.js, why callbacks were introduced, the problems they created, and how promises made async code cleaner and easier to manage.

Why Async Code Exists in Node.js

Node.js was designed to handle multiple tasks efficiently without blocking the main thread. Most backend operations take time to complete, such as:

• reading files

• querying databases

• calling APIs

• communicating over networks

If Node.js waited for every operation to finish before moving to the next task, the server would become slow and unresponsive.

Imagine a restaurant chef preparing food. If the chef stopped everything and waited beside the oven for one pizza to bake before taking new orders, the restaurant would quickly become chaotic.

Instead, a smart chef puts the pizza in the oven and continues preparing other dishes while waiting.

That’s exactly how Node.js handles asynchronous operations.

Starting with a File Reading Scenario

Let’s take a simple example. Imagine you want to read a large file from the system.

Here’s the synchronous version:

const fs = require("fs");

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

console.log(data);

console.log("Finished");

This code blocks execution. Node.js waits until the file is fully read before moving forward.

Now look at the asynchronous version :

const fs = require("fs");

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

console.log("Finished");

This time, Node.js starts reading the file and immediately continues executing the next line. That’s why "Finished" gets printed before the file content appears.

Instead of waiting, Node.js keeps moving.

Callback-Based Async Execution

The function passed inside readFile() is called a callback.

A callback is simply a function that runs later, after an operation completes.

In the previous example:

(err, data) => {
  console.log(data);
}

this function does not execute immediately. Node.js stores it temporarily and runs it once the file reading operation finishes.

Here’s the flow step-by-step:

  Start File Read
        ↓
  Node.js Continues Execution
        ↓
  File Reading Completes
        ↓
  Callback Function Executes

Callbacks became the foundation of asynchronous programming in early Node.js applications because they allowed the event loop to stay free while slow operations happened in the background.

Problems with Nested Callbacks

Callbacks solved the blocking problem, but they introduced another issue: deeply nested code.

Imagine a real-world situation where you need to:

1. Read a file

2. Fetch data from an API

3. Save something into a database

4. Send a response

Using callbacks, the code can quickly become messy.

readFile("user.txt", (err, fileData) => {
  fetchUserData(fileData, (err, userData) => {
    saveToDatabase(userData, (err, result) => {
      sendResponse(result, (err) => {
        console.log("Done");
      });
    });
  });
});

Notice how the code keeps moving deeper and deeper toward the right side.

This problem became famously known as:

“Callback Hell”

or sometimes:

“Pyramid of Doom”

The biggest issue wasn’t just appearance. Nested callbacks made code:

• harder to read

• difficult to debug

• painful to maintain

• harder to handle errors properly

As applications grew larger, developers needed a cleaner way to manage async operations.

Promise-Based Async Handling

To solve callback problems, JavaScript introduced Promises.

A Promise represents a value that may become available in the future.

Think of it like ordering food online.

When you place the order:

• you don’t receive the food immediately

• you receive a promise that the food will arrive later

The promise can eventually be:

• fulfilled → operation succeeded

• rejected → operation failed

const fs = require("fs").promises;

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

Now the flow feels much cleaner.

Instead of nesting callbacks inside callbacks, promises allow operations to be chained in a more readable way.

Promise Lifecycle

A Promise usually goes through three states:

  
  Pending
     ↓
  Fulfilled  → Success
     OR
  Rejected   → Error

When the async operation starts, the promise is in a pending state.

After completion:

• it becomes fulfilled if successful

• rejected if something fails

Comparing Callback vs Promise Readability

Let’s compare both approaches side-by-side.

Callback Style

getUser(id, (err, user) => {
  getPosts(user, (err, posts) => {
    getComments(posts, (err, comments) => {
      console.log(comments);
    });
  });
});

The code becomes deeply nested very quickly.

Promise Style

getUser(id)
  .then((user) => getPosts(user))
  .then((posts) => getComments(posts))
  .then((comments) => console.log(comments))
  .catch((err) => console.log(err));

This version is much easier to read because the operations flow linearly from top to bottom.

That readability is one of the biggest reasons promises became so popular in modern JavaScript and Node.js development.

Benefits of Promises

Promises improved asynchronous programming in several important ways.

They made code:

• cleaner and easier to read

• easier to maintain

• simpler to debug

• better for error handling

• easier to chain async operations together

Most modern Node.js APIs now support promises directly because they work much better for large-scale applications.

Promises also became the foundation for async/await, which made asynchronous code look even more synchronous and readable.

Real-World Example

Imagine an e-commerce application.

When a user opens their dashboard, the server may need to:

• fetch user details

• load recent orders

• retrieve notifications

• fetch payment information

All of these operations involve asynchronous tasks like database queries and API calls.

Without async programming, every user request would block the server while waiting for each operation to complete.

With callbacks and promises, Node.js can handle these tasks efficiently while still serving other users at the same time.

That’s one of the reasons Node.js performs so well for modern web applications.

Conclusion

Async programming is at the heart of Node.js.

Callbacks were the first major solution for handling asynchronous operations without blocking the event loop. They worked well, but deeply nested callbacks quickly became difficult to manage.

Promises improved this experience by making async code cleaner, more readable, and easier to maintain.

The important thing to remember is this:

Async code allows Node.js to stay productive while waiting for slow operations to complete.

And that single idea is what makes Node.js capable of handling massive numbers of requests efficiently.

“Never block the event loop.”

But what exactly does blocking mean? And why is non-blocking code such a big deal in Node.js?

To understand how Node.js handles thousands of requests efficiently, you first need to understand the difference between blocking and non-blocking execution.

What Blocking Code Means

Blocking code is code that stops the execution flow until a task finishes completely. While the operation is running, Node.js cannot move forward to execute the next piece of code.

Think of it like standing at a food counter waiting for your order. You place the order and then stand there doing absolutely nothing until the food arrives. Everything pauses during the waiting period.

That’s exactly how blocking code behaves.

In Node.js, operations like file reading, database queries, or network requests can take time. If the main thread waits for those operations to complete, the entire server becomes temporarily busy.

Here is a simple example :

const fs = require("fs");

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

console.log(data);

console.log("Finished");

In this example, readFileSync() blocks execution. Node.js will not move to the next line until the file is fully read. During this time:

• the event loop is paused

• incoming requests must wait

• server responsiveness decreases

Blocking Execution Timeline

  
  Start File Read
        ↓
  Waiting...
  Waiting...
  Waiting...
        ↓
  File Read Complete
        ↓
  Next Code Executes

This may not look dangerous in small applications, but on a production server handling thousands of users, blocking operations quickly become a serious performance problem.

What Non-Blocking Code Means

Non-blocking code works differently. Instead of waiting for a task to finish, Node.js starts the operation, delegates it to the system, and immediately continues executing other code.

This allows the server to remain responsive even while slow operations are happening in the background.

Here’s the non-blocking version of the same file read:

const fs = require("fs");

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

console.log("Finished");

This time, Node.js starts reading the file and immediately moves ahead. You’ll actually see "Finished" printed before the file content appears because the file operation happens asynchronously in the background.

Instead of waiting, Node.js keeps moving.

Non-Blocking Execution Timeline

  Start File Read
        ↓
  Continue Executing Other Code
        ↓
  Handle Other Requests
        ↓
  File Read Completes
        ↓
  Callback Executes

This behavior is one of the main reasons Node.js performs so efficiently under heavy traffic.

Why Blocking Slows Servers

Node.js uses a single main thread for JavaScript execution. That means if one operation blocks the thread, every other request also has to wait.

Imagine a restaurant with only one chef. If the chef spends 20 minutes preparing one complicated dish while ignoring everyone else, the entire restaurant slows down. New customers keep arriving, but nobody gets served until the chef finishes the current task.

Blocking code creates the same situation inside a server.

For example:

const data = fs.readFileSync("hugeFile.txt");

While this file is being read:

• no other JavaScript can execute

• incoming API requests are delayed

• the event loop cannot continue processing tasks

Even fast requests become slow because one blocking task occupies the thread.

This is why synchronous methods like:

• readFileSync()

• heavy loops

• CPU-intensive calculations

should be used very carefully in Node.js applications.

Async Operations in Node.js

Node.js was built around asynchronous execution. Most backend tasks involve waiting for something external, such as:

• database responses

• API calls

• file systems

• network communication

Instead of waiting idly, Node.js delegates these operations and continues handling other users.

Under the hood, Node.js uses:

• the event loop

• async I/O

• background workers

• operating system APIs

to make this possible.

This architecture allows thousands of requests to remain “in progress” simultaneously without creating thousands of threads.

Real-World Examples

A very common example is file handling.

Using blocking code:

const fs = require("fs");

const data = fs.readFileSync("report.pdf");

console.log("File Loaded");

The server pauses until the file finishes loading.

Now compare that with the asynchronous version:

const fs = require("fs");

fs.readFile("report.pdf", (err, data) => {
  console.log("File Loaded");
});

Here, the file operation happens in the background while the server continues handling other users.

Why Non-Blocking Makes Node.js Fast

Most web applications are not CPU-heavy. They are mostly waiting for I/O operations like databases, APIs, and file systems.

Node.js takes advantage of this by using waiting time efficiently. Instead of freezing the server during I/O operations, it keeps serving other requests.

This makes Node.js especially powerful for applications like:

• REST APIs

• chat systems

• streaming platforms

• real-time dashboards

• multiplayer applications

The architecture is lightweight, memory efficient, and highly scalable because the main thread rarely sits idle.

Conclusion

The difference between blocking and non-blocking code is one of the most important concepts in Node.js development.

Blocking code pauses execution and slows down the server. Non-blocking code allows Node.js to continue processing other tasks while slow operations happen in the background.

The core idea is simple:

Blocking code waits.
Non-blocking code keeps moving.

And that single difference is what makes Node.js capable of handling massive numbers of concurrent requests so efficiently.

“If there’s only one thread, how can Node.js handle thousands of users at the same time?”

Traditional backend servers often create a separate thread for every incoming request. More users means more threads. More threads means more memory usage and more CPU overhead.

Node.js takes a completely different approach.

Instead of creating a thread for every request, Node.js follows a much smarter idea:

Don’t wait. Delegate the work and keep moving.

That simple principle is what makes Node.js extremely fast and scalable for modern web applications.

In this article, we’ll understand how Node.js handles multiple requests using a single thread, how the event loop works, and why this architecture performs so well.

Single Threaded Nature of Node.js

Before understanding Node.js, let’s simplify two important terms process and thread :

Process vs Thread

A process is a running application.

For example:

• Chrome browser = one process

• VS Code = another process

• Your Node.js app = another process

A thread is a worker inside that process.

Think of a restaurant kitchen:

• Kitchen = process

• Chefs = threads

Many traditional servers use multiple chef threads to handle multiple requests simultaneously but Node.js works differently.

Node.js Uses a Single Main Thread

Node.js runs JavaScript on:

• one main thread

• one call stack

• one memory heap

This means only one piece of JavaScript executes at a time.

At first, this sounds like a limitation.
But most backend applications spend the majority of their time:

• waiting for databases

• waiting for APIs

• waiting for file systems

• waiting for network responses

These are called I/O operations.

Instead of sitting idle and waiting for these operations to finish, Node.js delegates them and keeps handling other requests.

That’s the foundation of Node.js architecture.

Event Loop Role in Concurrency

The real power of Node.js comes from the Event Loop.

The event loop is a continuously running mechanism that checks:

1. Is there a new task?

2. Is any async task completed?

3. Is there a callback waiting to execute?

It keeps repeating this cycle extremely fast.

The Chef Analogy

Imagine a restaurant with only one chef.

A blocking system would work like this:

1. Take Order #1

2. Cook it completely

3. Deliver it

4. Then take Order #2

Every customer waits.

How Node.js Works

Node.js behaves like a smart chef.

1. Takes Order #1

2. Puts steak on the grill

3. Sets a timer

4. Immediately starts Order #2

5. Then Order #3

The chef doesn’t stand there watching the steak cook.

Instead:

• the grill handles cooking

• timers notify when food is ready

• the chef keeps serving customers

That chef is the Event Loop.

This is how Node.js handles many requests concurrently without blocking the main thread.

Concurrency vs Parallelism

This is one of the most misunderstood concepts.

Concurrency :

Concurrency means:

Multiple tasks making progress without blocking each other.

Node.js is primarily concurrent.

Parallelism :

Parallelism means:

Multiple tasks literally running at the same exact time on multiple CPU cores.

Node.js does not execute JavaScript in parallel by default.

Instead, it efficiently switches between tasks using the event loop.

Delegating Tasks to Background Workers

Here’s something many beginners don’t realize:

Node.js is single-threaded for JavaScript execution, but not everything runs on that single thread.

Under the hood, Node.js uses:

libuv

libuv provides:

• the event loop

• async I/O handling

• thread pool support

What Gets Delegated?

Certain operations are too slow to execute directly on the main thread.

Examples include:

• file system operations

• DNS lookups

• cryptography

• compression

These tasks are delegated to background worker threads.

Meanwhile, the main thread remains free to handle incoming requests.

For network operations like HTTP requests and database communication, Node.js often relies directly on the operating system’s asynchronous I/O system.

Visual Flow

  Client Request
        ↓
  Main Thread Receives Request
        ↓
  Async Task Delegated
        ↓
  Background Worker / OS
        ↓
  Task Completes
        ↓
  Callback Queue
        ↓
  Event Loop Executes Callback
        ↓
  Response Sent

Handling Multiple Client Requests

Let’s say three users hit your API at the same time.

app.get("/", async (req, res) => {
  const users = await fetchUsers();
  res.json(users);
});

Here’s what happens internally.Here’s what happens internally.

Step 1: Request Arrives

User A sends a request.

The main thread receives it.

Step 2: Async Task Starts

The database query is delegated immediately.

The main thread does not wait.

Step 3: Event Loop Continues

While User A’s database query runs in the background:

• User B request arrives

• User C request arrives

Node.js accepts both immediately.

Step 4: Completed Tasks Return

When database results are ready:

• callbacks enter the queue

• event loop picks them up

• responses are sent

This creates the illusion that many things are happening simultaneously.

But internally:

• JavaScript still runs on one thread

• Node.js simply avoids blocking it

Blocking vs Non-Blocking Example

Blocking Code :

const data = fs.readFileSync("largeFile.txt");
console.log(data);

Problem:

• execution stops

• event loop waits

• other requests cannot be processed

Non-Blocking Code :

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

Here:

• file reading happens in background

• event loop continues running

• other users can still be served

This non-blocking behavior is the reason Node.js performs so efficiently.

Why Node.js Scales Well

Node.js performs exceptionally well for I/O-heavy applications because of its lightweight architecture.

Low Memory Usage

Traditional servers create one thread per request.

More threads mean:

• more RAM usage

• more CPU scheduling

• more overhead

Node.js avoids this by using a single event loop.

Thousands of connections can remain open with relatively low memory usage.

Efficient Handling of I/O Operations

Most backend applications spend more time waiting than computing.

For example:

• waiting for databases

• waiting for APIs

• waiting for file reads

Node.js uses this waiting time efficiently by continuing to serve other users.

Minimal Context Switching

In multi-threaded systems, the operating system constantly switches between threads.

This process is called context switching, and it adds overhead.

Since Node.js mainly uses one thread for JavaScript execution, it avoids most of that overhead.

Best for Real-Time Applications

Node.js works especially well for:

• APIs

• chat applications

• streaming platforms

• real-time dashboards

• multiplayer games

Anywhere many users stay connected simultaneously, Node.js performs extremely well.

Conclusion

The biggest misconception about Node.js is:

“Single-threaded means it can only handle one request at a time.”

That’s not true.

Node.js handles thousands of concurrent requests efficiently because it never wastes time waiting for slow operations to complete.

Instead:

• async tasks run in the background

• the event loop keeps moving

• completed operations return through callbacks

The result is a lightweight, fast, and highly scalable backend architecture.

Once you understand the event loop and non-blocking I/O, the magic behind Node.js starts making perfect sense.

In this article, we'll break everything down step by step, starting from the problem the Virtual DOM was designed to solve, all the way to how React updates only the necessary parts of the UI to keep your app smooth and performant.

The Problem: Why Direct DOM Manipulation Is Slow

To understand why the Virtual DOM exists, you first need to understand the problem it solves.

The browser's Real DOM, or Document Object Model, is a tree-like structure of your HTML elements. Whenever something changes on the page, like updating text, adding an element, or changing a class name, the browser has to perform several tasks:

• Recalculate styles

• Reflow the layout to reposition elements

• Repaint the updated content on the screen

These operations are expensive, especially when updates happen frequently.

For small websites, this is usually fine. But modern web apps constantly update their UI. Users type into inputs, lists refresh, counters change, and components re-render. If every change directly updates the Real DOM, the browser ends up doing a lot of unnecessary work.

This was a common problem in early jQuery applications. Developers manually updated DOM elements, but as apps became more complex, keeping the UI in sync became difficult and error-prone.

React introduced the Virtual DOM to make this update process faster and more efficient.

Real DOM vs Virtual DOM

Before understanding how React works internally, it's important to know the difference between the Real DOM and the Virtual DOM.

The Real DOM is the actual tree of HTML elements that the browser renders on the screen. It is heavy and expensive to update because every change can trigger layout calculations and re-rendering.

The Virtual DOM is a lightweight JavaScript object that mirrors the Real DOM. It is just data, so creating and updating it is much faster.

Think of the Real DOM as the actual house, and the Virtual DOM as its blueprint. Changing a blueprint is quick and easy, while modifying the real house takes more effort.

React first updates the Virtual DOM, finds the minimum changes required, and then updates only those parts in the Real DOM.

Here's a simple mental model of what a Virtual DOM node looks like:

// JSX you write:

<div className="card">
  <h2>Hello, World</h2>
  <p>Welcome to React</p>
</div>


// Gets turned into a Virtual DOM object like:
{
  type: 'div',
  props: { className: 'card' },
  children: [
    {
      type: 'h2',
      props: {},
      children: ['Hello, World']
    },
    {
      type: 'p',
      props: {},
      children: ['Welcome to React']
    }
  ]
}

This object lives entirely in memory. React can create, compare, and throw away these objects at will, all without touching the browser.

The Initial Render Process

When your React application loads for the first time, this is what happens step by step:

Step 1 - React reads your components
You create components as functions or classes that return JSX. React calls these components and collects their JSX output.

Step 2 - JSX gets converted into JavaScript
JSX is not understood directly by the browser. Babel compiles it into React.createElement() calls, which create Virtual DOM objects.

Step 3 - React creates the Virtual DOM tree
Starting from the root component, usually <App />, React recursively processes all components and builds one complete Virtual DOM tree.

Step 4 - React updates the Real DOM
React converts the Virtual DOM into actual DOM elements and inserts them into the browser. This is the only time React builds the entire UI from scratch. Future updates only change the necessary parts instead of rebuilding everythin g.

 Component Functions
        ↓
     JSX → React.createElement()
        ↓
  Virtual DOM Tree (in memory)
        ↓
  Real DOM (browser renders it)

How State or Props Changes Trigger a Re-render

Once the app is running, a state or prop change can trigger a re-render. For example, a user clicks a button that calls setState, or a parent component passes new props.

React marks that component as needing an update. During the next render cycle, React calls the component again with the updated state or props. The component returns new JSX, and React creates a new Virtual DOM tree from it.

An important thing to understand is that React does not update the Real DOM immediately. It first creates the updated Virtual DOM completely in memory, then compares it with the previous version.

This is what makes React efficient. Most of the work happens on lightweight JavaScript objects, while the Real DOM is updated only where changes are actually needed.

Creating a New Virtual DOM Tree

Every time a component re-renders, React creates a new Virtual DOM subtree for that component and its children. This new tree represents how the UI should look based on the latest state and props.

Consider a simple counter:

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

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

When count is 0, the Virtual DOM tree looks like:

{
  type: 'div',
  children: [
    { type: 'p', children: ['Count: 0'] },
    { type: 'button', children: ['Increment'] }
  ]
}

After the button is clicked, count becomes 1, and React creates a new Virtual DOM tree:

{
  type: 'div',
  children: [
    { type: 'p', children: ['Count: 1'] },  // ← changed
    { type: 'button', children: ['Increment'] }  // ← same
  ]
}

At this point, React has two Virtual DOM trees, the old tree from the previous render and the new tree from the current render. React then compares both trees to find what has changed.

Diffing and Reconciliation

Reconciliation is the process React uses to compare the old Virtual DOM tree with the new one to detect changes. This comparison process is called diffing.

Comparing two large trees can be very expensive, but React uses smart rules to make it fast and efficient.

Rule 1 - Different element types create different trees
If a <div> changes to a <section>, React removes the old subtree and creates a new one instead of comparing them deeply.

Rule 2 - Keys help React track list items
When rendering lists, React uses the key prop to identify items between renders. Without keys, React assumes items in the same position are the same, which can cause incorrect updates.

This is why React warns you about missing keys in lists. Keys help the diffing algorithm work correctly and efficiently.

How React Finds the Minimal Required Changes

During diffing, React compares the old and new Virtual DOM trees node by node.

At each step, React checks:

• Is the element type the same?
  If a <p> is still a <p>, React keeps the existing DOM node. If the type changes, React removes the old node and creates a new one.

• Did the props change?
  If properties like className, style, or onClick changed, React updates only those specific attributes.

• Did the children change?
  React recursively compares child elements and applies the same process.

• For lists, do the keys match?
  React uses key props to identify which items were added, removed, or moved.

After diffing, React creates a minimal list of updates needed for the Real DOM. For example, in a counter app, React may only update the text from "Count: 0" to "Count: 1" while leaving the button unchanged.

Updating Only the Changed Nodes in the Real DOM

Once diffing is finished, React enters the commit phase. This is the stage where React finally updates the browser's Real DOM.

React only applies the changes identified during diffing, such as:

• Updating text content

• Changing an attribute

• Adding a new DOM element

• Removing an old element

Since React already calculated everything using the Virtual DOM, the actual DOM updates are minimal and efficient. This reduces expensive browser operations like reflow and repaint.

In a counter example, React only updates the text inside the <p> tag from "Count: 0" to "Count: 1". The <button> and the rest of the page remain unchanged.

Why This Approach Improves Performance

Now let's understand why this architecture works so well.

Batching updates
React can combine multiple state updates into a single render cycle. Instead of updating the DOM multiple times, React creates one optimized update.

Avoiding unnecessary work
React compares the old and new Virtual DOM trees first. If nothing changed, it skips updating the Real DOM completely.

Reducing expensive browser operations
Traditional JavaScript often mixes DOM reads and writes, which can force repeated layout recalculations. React avoids this by applying DOM updates together during the commit phase.

Predictable UI updates
Since React manages DOM updates itself, the UI stays in sync with the application state without manual DOM handling.

The Virtual DOM is not magic, it also has some overhead because React needs to create and compare JavaScript objects. But in most real-world applications, reducing expensive Real DOM operations gives a much bigger performance benefit.

The Full React Update Lifecycle: Render → Diff → Commit

Let's tie everything together into one clear flow.

┌──────────────────────────────────┐
│             TRIGGER                                  │
│ State / Props / forceUpdate                          │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│          RENDER PHASE                                │
│ React re-renders components                          │
│ Creates new Virtual DOM tree                         │
│ No Real DOM updates yet                              │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│           DIFF PHASE                                 │
│ Compare old vs new VDOM                              │
│ Detect changed nodes                                 │
│ Create minimal patch list                            │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│         COMMIT PHASE                                 │
│ Update changed Real DOM nodes                        │
│ Browser repaints necessary UI                        │
│ useEffect runs after commit                          │
└──────────────────────────────────┘

The React update process is divided into three main phases:

Render phase - React calculates what the UI should look like based on the latest state and props. This work happens only in memory using the Virtual DOM.

Diff phase - React compares the new Virtual DOM tree with the previous one to find what changed. This is where reconciliation happens.

Commit phase - React updates the Real DOM with only the required changes. Effects like useEffect also run after this phase.

Conclusion

The Virtual DOM is one of React's core concepts, but its main purpose is simple, keeping the UI updated efficiently without developers manually handling DOM changes.

Here’s the mental model to remember:

• The Real DOM is expensive to update

• The Virtual DOM is a lightweight in-memory copy

• React compares the old and new Virtual DOM trees through diffing

• Only the required changes are applied to the Real DOM

This render → diff → commit cycle keeps running as users interact with your app, state changes, or new data arrives. React handles the complex DOM updates internally, so developers only need to describe how the UI should look for a given state.

Understanding this flow also helps you use optimization tools like React.memo, useMemo, useCallback, and key props more effectively, because all of them help React reduce unnecessary work during diffing.

The answer can be found in one of the most important concept of Node.js : The Event Loop.

In this article we are going to understand everything about Event loop and it's internals in detail.

The Problem :

Javascript was originally designed for browsers, an environment where only one UI thread runs at a time.

Node.js inherited the same model, this means Node.js can only execute one piece of code at any given point of time. There is no parallel execution of JS code by default.

This is not good for any web server, imagine 1000 users hit your server at the same moment, and each request requires a 2 seconds to complete the databse query. A traditional multi-threaded server would spin a new thread for each request, means 1000 threads running in parallel. It works, but it is expensive, each thread will also consume memory (roughly 1-2 mb), and coordinating between threads will increase complexity.

Node.js uses a very different approach, instead of handling parallel execution through threads, it handles it through a mechanism called the Event Loop, by never blocking and delegating works that involves waiting.

What Is Event Loop ?

In general, we can assume the event loop as a smart and tireless task manager, which runs a continuous check of :

• Check if the call stack is empty or is JavaScript currently executing anything?

• If the stack is empty, check the queues are there any callbacks waiting to be run?

• If there are, pick the highest-priority one and push it onto the call stack for execution.

• Repeat this forever until the program ends.

We can understand the flow of event loop with below diagram :

This event loop, never sleeps, never blocks, it never waits, and never does any computation itself. It is purely an orchestrator, constantly checking, picking, and dispatching.

Why Node.js Needs An Event Loop

Without the event loop :

• Every request will blovk the thread

• No parallel handling of user

• Poor perfomrance and scalabiliy

With the event loop:

• Non-blocking execution

• Faster response handling

• Efficient resource usage

Two Pillers Of The Event Loop :

To understand the Event Loop deeply, we need to understand the two data structures event loop bridges:

1. Call Stack

2. Task Queue

Call Stack :

The call stack is the area where the Javascript functions actually executes. It works like a stack of items, whichever comes last, goes out first ( LIFO : Last in First out ).

When a function is called, a new frame is pushed onto the top of the call stack, when it returns, the frame is popped off. This stack can only process one frame at a time, and it processes them synchronously from top to bottom. If a function takes 3 seconds to complete, the entire stack is frozen for those 3 seconds.

Task Queue :

The task queue, aslo called the callback queue is a waiting room for async callbacks, when an async operation completes, a timer fires, a file finishes reading, a network response arrives. It's callback is placed here. The queue works on the approach of FIFO : First in First out.

Crucially, callbacks in this queue do nothing until the event loop picks them up and the call stack is empty.

These two structures form the backbone of everything async in Node.js. The call stack is where work happens right now. The task queue is where work waits to happen later. The event loop is what connects them.

How Async Operations Really Work :

When you call async function like setTimeout, fs.readFile or fetch, Node.js does not pause and wait for it to finish, It hands off the work to libuv.

libuv is C library, which works with Node.js that interface directly with the Operating System's async APIs.

libuv manages a thread pool for I/O-heavy work and uses OS-level event notification systems (like epoll on Linux or kqueue on macOS) to know when operations complete.

This means the Node.js JavaScript thread is free to keep running while libuv handles the heavy lifting in the background. When the OS reports that an operation is done, libuv puts the callback into the appropriate queue. The event loop picks it up the next time the call stack is clear.

console.log("Start");        
// 1. Pushed onto stack, runs immediately


setTimeout(() => {
  console.log("Timer done"); 
}, 2000);                     
// 3. Runs AFTER the stack is empty (not "after 2 seconds" exactly)


console.log("End");          
// 2. Pushed onto stack, runs immediately

1  Start
2  End
3  Timer done

What happens step by step: console.log("Start") runs synchronously. setTimeout is encountered : Node immediately registers the timer with libuv and moves on without waiting. console.log("End") runs synchronously.

Now the stack is empty. After 2 seconds, libuv places the timer callback in the queue. The event loop detects the empty stack, picks the callback, and runs it. Only then does "Timer done" print.

Timers vs I/O Callbacks

Node.js handles different types of async operations in separate queues, and understanding the difference between the two main categories is important.

Timers :

setTimeout() and setInterval() are time-based. Their callbacks enter the timer queue after a specified minimum delay has elapsed. "Minimum" is important here, if the event loop is busy processing something else when the timer fires, the callback waits until the current work is done. You can't guarantee exact timing with these.

I/O Callbacks

File reads, database queries, HTTP requests etc. these are completion-based. Their callbacks fire when the OS reports the operation is finished, regardless of time. A fast SSD might complete a file read in microseconds; a slow network request might take 5 seconds. The callback fires when it's ready, not on a clock.

The key conceptual difference: timers depend on time passing, I/O depends on something external finishing. Both go through libuv, and both end up in queues that the event loop manages, but they live in different queues with different priorities.

Queue Priority (The Order That Matters)

Not all queues are treated equally by the event loop. Every single "tick" of the loop, it processes queues in a strict, defined order.

Microtasks always cut the queue. A resolved Promise.then() will always run before any setTimeout(fn, 0), even if both are ready at the same time.

Role of Event Loop in Scalability

All of this design has a powerful payoff. Because Node.js never creates a new thread per request, the memory cost of concurrency is dramatically lower than traditional servers.

• 10,000 concurrent connections in Node.js = 10,000 callbacks in a queue, not 10,000 threads eating RAM.

• No thread synchronization required — one thread means no race conditions in your application code.

• I/O operations never block the main thread — while one request waits for a DB query, the event loop is already handling the next request.

• Startup is fast, memory footprint stays lean even under heavy traffic.

This is why Node.js is the go-to choice for real-time applications (chat, live notifications, multiplayer games), REST APIs that are I/O-bound rather than CPU-bound, and streaming services where thousands of open connections must be maintained simultaneously.

Real World Analogy

Here's a mental model that maps the whole system to something familiar.

The manager (event loop) never cooks and never takes food to tables. They just keep the kitchen running — the instant the chef (call stack) finishes one dish, the manager hands them the next ticket (callback). And when the kitchen is completely empty and quiet, the manager stands by the door waiting for the next customer order to arrive — that's the event loop blocking on the OS when all queues are empty, waiting for new I/O events.

Before diving into the advance features, It is a good idea to know about the basic commands of Linux file system.

Filesystem Commands ( Frequently used )

There are several commands in linux to perform different tasks. Here is the list of few commands, based on their use cases :

Navigation & Structure

pwd          # Current directory
ls           # List files
cd <dir>     # Move between directories
tree         # Visualize folder structure

File Operations

touch file.txt    # touch command for file creation
mkdir folder      # mkdir for creating directory 
cp file1 file2    # cp command for copying data from one file to another
mv old new        # mv command to move data from old file to new one
rm file           # rm command to delete the file

Reading System Files

cat <file>
less <file>
head <file>
tail -f <file>

Searching & Investigation

find / -name "file"
grep "text" file
locate filename

There are a lot more commands available in Linux, other then above commands.

Let's discuss about the findings during the research of linux commands

The linux file system, is not just storage mechanism or filesystem, but it is a live interface to the Kernel itself.

Finding 1 : The Routing Table is Just a File

Path : /proc/net/route

The kernel maintains a live routing table, the logic that decides where every outgoing packet goes and exposes it as a plain text file at /proc/net/route. No tool required. No daemon to query. Just a file.

Each row is a route. The columns are hex-encoded: destination, gateway, flags, interface. The system reads this to decide whether a packet should go to the local network or out through the default gateway.

cat /proc/net/route
# Iface  Destination  Gateway   Flags  ...  Mask
# eth0   00000000     0101A8C0  0003        00000000  ← default route → 192.168.1.1
# eth0   0001A8C0     00000000  0001        00FFFFFF  ← local subnet

/proc is not a real disk; it's a virtual filesystem the kernel generates on-the-fly. Reading /proc/net/route is essentially reading a live kernel data structure without any syscall overhead beyond a plain file read.

Finding 2 : DNS Is Not the First Stop

Path: /etc/nsswitch.conf

Many people assume that when you type a hostname, Linux immediately fires a DNS query. But it doesn't. The actual resolution order is controlled by /etc/nsswitch.conf, the Name Service Switch configuration. One line controls everything :

hosts: files dns mdns4_minimal

This means: check /etc/hosts first, then DNS, then mDNS. Before a single DNS packet leaves your machine, the kernel checks the local hosts file. This is why sysadmins can override any domain locally add an entry to /etc/hosts and it wins over DNS every time, unless nsswitch is reconfigured.

Security implication: Malware sometimes modifies /etc/hosts to redirect banking domains to phishing IPs. Since files comes before dns in the default config, this works silently, without touching any DNS server, without any network anomaly to detect.

Finding 3 : Every Process Keeps Its Open Files

Path: /proc/[pid]/fd/

Every running process has a directory at /proc/[pid]/fd/ containing symbolic links, one for each open file descriptor. This includes open log files, sockets, pipes, devices, and config files.

ls -la /proc/$(pgrep nginx)/fd
# 0 → /dev/null
# 1 → /dev/null
# 4 → socket:[38291]
# 5 → /var/log/nginx/access.log

What's remarkable : if a process opens a file and that file is then deleted from disk, the process still holds the file descriptor open. The file's data survives on disk, invisible from the directory tree, but still readable via /proc/[pid]/fd/[n].

The ghost file phenomenon: This is a known disk space recovery trick. If df shows a disk is full but du shows low usage, a deleted-but-still-open log file is silently holding the space. You can truncate it via its fd path and reclaim the space without killing the process. The file is gone from the directory, but alive in /proc.

Finding 4 : Privilege Is Just a Text File

Path: /etc/sudoers

The entire privilege escalation model of Linux rests on a single text file. /etc/sudoers defines exactly who can run what as whom. Its syntax is precise and unforgiving, a mistake here can lock out all admin access permanently.

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

# This line lets the "deploy" user restart nginx without a password:
deploy  ALL=(root) NOPASSWD: /bin/systemctl restart nginx

The NOPASSWD directive is powerful for automation, but catastrophic if misconfigured. A wildcard like NOPASSWD: ALL on a service account is functionally equivalent to giving that account root access without any authentication.

Finding 5 : One File Turns Linux Box Into a Router

Path: /proc/sys/net/ipv4/ip_forward

There is a single file that controls whether Linux will forward network packets between interfaces, the defining behavior of a router. It contains either 0 or 1.

cat /proc/sys/net/ipv4/ip_forward
0   # not routing

echo 1 > /proc/sys/net/ipv4/ip_forward
# Now this machine forwards packets between interfaces.
# Combined with iptables NAT rules → full router or VPN gateway.

VPNs, Docker networking, Kubernetes pod routing, and NAT gateways all depend on this being set to 1. Every container platform enables this silently at startup, through a single write to a single file.

Finding 6 : How the OS Finds Shared Libraries

Path: /etc/ld.so.conf and /etc/ld.so.cache

When a program launches, the dynamic linker needs to find .so shared library files. The directories it searches are listed in /etc/ld.so.conf and files inside /etc/ld.so.conf.d/.

These are compiled into a fast binary cache at /etc/ld.so.cache by running ldconfig.

cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

The LD_PRELOAD hijacking attack: The LD_PRELOAD environment variable forces a library to load before anything else, overriding the standard library search entirely. Attackers use this to intercept system calls at the libc level. Classic rootkits used LD_PRELOAD to hide processes from ps by overriding the very libc functions used to enumerate them. The process was running; ps just never saw it.

Finding 7 : The Auth Log Knows Everything

Path: /var/log/auth.log

The auth log knows everything about who came in.

Every authentication event, successful login, failed login, sudo usage, SSH key acceptance, is written to /var/log/auth.log (on Debian/Ubuntu; /var/log/secure on RHEL/CentOS). It is the system's silent witness.

Apr 22 03:14:22 sshd[2891]: Failed password for root from 45.33.32.156 port 43212 ssh2
Apr 22 03:14:23 sshd[2891]: Failed password for root from 45.33.32.156 port 43212 ssh2
Apr 22 09:01:11 sudo:  alice : TTY=pts/1 ; USER=root ; COMMAND=/bin/cat /etc/shadow

That last line is alarming: alice used sudo to read /etc/shadow the file containing all password hashes. Auth logs are the first place to check after any suspected breach.

Finding 8 : Scheduled Tasks Are Scattered Across the Filesystem

Paths: /etc/cron.d/ · /etc/cron.daily/ · /var/spool/cron/crontabs/

Most people know about crontab -e. What they don't realize is that cron jobs live in at least four different locations. Package managers drop cron jobs in /etc/cron.d/. The system runs daily/weekly/monthly scripts from /etc/cron.daily/, /etc/cron.weekly/, and so on. User-specific crontabs live in /var/spool/cron/crontabs/[username].

ls /etc/cron.d/
# certbot   e2scrub_all   php   sysstat

cat /etc/cron.d/certbot
# 0 */12 * * * root certbot renew -q

Certbot silently auto-renews your TLS certificates every 12 hours, a cron job you probably never set up yourself, living in a directory you may never check.

Finding 9 : Devices That Aren't Physical

Path: /dev/null, /dev/zero, /dev/random

The /dev directory contains device files, but not all of them represent hardware. Three of the most useful are entirely virtual, implemented purely in kernel code.

/dev/null is the black hole. Anything written to it is discarded. Reading from it returns EOF immediately. It exists to silence output you don't care about.

/dev/zero produces an infinite stream of zero bytes. It's used to create empty files of exact sizes, dd if=/dev/zero of=disk.img bs=1M count=100 creates a precise 100MB blank file, useful for disk image creation and benchmarking.

/dev/random and /dev/urandom are sources of cryptographically random bytes, fed by entropy gathered from hardware events: keystrokes, disk I/O timing, network packet arrival. Every TLS key, SSH key, and cryptographic token generated on Linux is seeded from here.

Finding 10 : Reading Live TCP Connections Without Any Tool

Path: /proc/net/tcp

Here is something that genuinely surprised me: netstat and ss have no special kernel access. They are just reading /proc/net/tcp , a file that lists every active TCP socket in the kernel right now, in plain text. The tools just decode it for you.

cat /proc/net/tcp
#  sl  local_address  rem_address  st  ...  inode
   0:  00000000:0016  00000000:0000  0A  ...  12938   ← LISTEN on port 22 (SSH)
   1:  0F02000A:0016  0202000A:C4E2  01  ...  18342   ← ESTABLISHED connection

The addresses are little-endian hex. 0016 hex = 22 decimal — that's SSH. State 0A = LISTEN. State 01 = ESTABLISHED. The inode column links the socket back to a specific process via /proc/[pid]/fd/.

Decoding the address manually:

# 0F02000A → bytes reversed: 0A 00 02 0F → 10.0.2.15
printf '%d.%d.%d.%d\n' 0x0A 0x00 0x02 0x0F
# 10.0.2.15

Conclusion

The deeper insight from this investigation is architectural. Linux exposes its own internals as files. Routing tables, process state, socket connections, kernel tunables, all of it is readable, and sometimes writable, through the filesystem. This is not accidental. It is the Unix philosophy made real: everything is a file, and files can be read.

If you understand the filesystem, you understand the system. You don't need a monitoring tool if you can read /proc. You don't need a network scanner if you can parse /proc/net/tcp. The OS is already telling you everything, you just need to know where to look.

Both are written with three dots ... which is exactly why they confuse so many people. They look identical. But they do opposite things depending on where and how you use them. One expands values out, the other collects values in. Once you internalize that contrast, the two become very easy to tell apart.

Spread = Expands values

Rest = Collects values

Why These Operators Are Important

They help:

• Simplify code

• Handle data easily

• Improve readability

1. What the Spread Operator Does

The spread operator takes an array or object and expands it into individual elements out into a new context.

Think of it like unpacking a suitcase: you take everything that was bundled together and lay each item out separately.

const fruits = ['apple', 'banana', 'mango'];

// spread operator
console.log(...fruits); // apple banana mango
//         ↑ spread unpacks the array into three separate values

Instead of passing the whole array as one thing, spread breaks it apart and hands over each element individually. This becomes very useful when you need to pass array items as separate arguments to a function.

const numbers = [4, 1, 7, 2];

console.log(Math.max(...numbers)); // 7
// Math.max doesn't accept an array — it needs individual values
// spread converts [4, 1, 7, 2] into Math.max(4, 1, 7, 2)

Without spread, you'd have to manually write Math.max(4, 1, 7, 2) or use an older workaround like .apply(). Spread makes this elegant and readable.

2. What the Rest Operator Does

The rest operator does the exact opposite, it collects multiple individual values and bundles them together into a single array. If spread is unpacking a suitcase, rest is packing one.

The most common place you'll see rest is in function parameters, where it gathers all the extra arguments passed into a function:

function sum(...numbers) {
  // `numbers` is now an array of everything passed in
  return numbers.reduce((total, n) => total + n, 0);
}

sum(1, 2, 3);       // 6
sum(10, 20, 30, 40); // 100

Here, no matter how many arguments you pass to sum, the rest operator collects all of them into the numbers array. The function doesn't need to know in advance how many values it will receive, rest handles that flexibility for you.

3. The Difference Between Spread and Rest

Even though they share the same ... syntax, the key to telling them apart is asking: is this expanding values out, or collecting values in?

Spread appears where values are being used, in function calls, array literals, or object literals. It takes something bundled and spreads it open. Rest appears where parameters or variables are being defined, in function signatures or destructuring. It takes loose individual values and wraps them up.

A side-by-side comparison makes this very clear:

// SPREAD — expanding an array into a function call
const nums = [1, 2, 3];
console.log(Math.max(...nums)); // spread at the call site

// REST — collecting arguments inside a function definition
function add(...nums) {        // rest in the parameter list
  return nums.reduce((a, b) => a + b, 0);
}

Both lines use ...nums, but the first is spreading outward and the second is collecting inward. The position call site vs. definition, is what tells you which one it is.

4. Using Spread with Arrays and Objects

Spread really shines when working with arrays and objects, particularly for creating copies and combining data without mutating the originals.

Copying an array without affecting the original:

const original = [1, 2, 3];
const copy = [...original]; // a fresh, independent array

copy.push(4);
console.log(original); // [1, 2, 3] — untouched
console.log(copy);     // [1, 2, 3, 4]

This is important because in JavaScript, assigning an array directly (const copy = original) doesn't create a copy — both variables point to the same array. Spread gives you a true, independent copy.

Merging arrays is equally clean:

const veggies = ['carrot', 'pea'];
const fruits  = ['apple', 'mango'];

const food = [...veggies, ...fruits, 'rice']; // mix and match freely
// ['carrot', 'pea', 'apple', 'mango', 'rice']

Spread works just as naturally with objects. You can copy or merge objects the same way:

const defaults = { theme: 'light', fontSize: 14, language: 'en' };
const userPrefs = { fontSize: 18, language: 'hi' };

// Merge: userPrefs values override defaults where they overlap
const settings = { ...defaults, ...userPrefs };
// { theme: 'light', fontSize: 18, language: 'hi' }

Notice that fontSize and language from userPrefs overwrite the values from defaults, while theme — which only exists in defaults — is preserved. This pattern of spreading defaults first and then spreading user-provided values on top is extremely common in real codebases.

5. Practical Use Cases

Knowing the mechanics is one thing, seeing where these operators actually appear in everyday code is what makes them stick. Adding items to an array without mutating it is a very common need, especially in frameworks like React where you're expected to treat data as immutable:

const cart = ['shoes', 'shirt'];

// Add an item by creating a new array instead of using push()
const updatedCart = [...cart, 'hat'];
// ['shoes', 'shirt', 'hat'] — cart itself is unchanged

Passing a dynamic list of arguments to any function that expects individual values:

const dates = [2024, 6, 15]; // year, month, day
const birthday = new Date(...dates); // same as new Date(2024, 6, 15)

Cloning and updating an object in one step, which you'll see constantly in state management:

const user = { name: 'Meera', age: 25, city: 'Pune' };

// Update age without mutating the original user object
const updatedUser = { ...user, age: 26 };
// { name: 'Meera', age: 26, city: 'Pune' }

Building flexible utility functions using rest, so they can accept any number of arguments:

function logWithPrefix(prefix, ...messages) { 
    // prefix is one fixed argument, messages collects the rest
    messages.forEach(msg => console.log([\({prefix}] \){msg})); 
}

logWithPrefix('INFO', 'Server started', 'Listening on port 3000');
// [INFO] Server started
// [INFO] Listening on port 3000

This kind of function is far more flexible than one that accepts a fixed number of arguments. You can pass two messages or ten, it handles all of them gracefully.

Conclusion

Spread and rest are two sides of the same coin. Spread takes a collection and fans it out into individual pieces, useful when you need to pass, copy, or combine data. Rest takes individual pieces and gathers them into a collection, useful when you want a function to handle a variable number of arguments or when you want to capture "the remainder" in a destructuring pattern.

The three dots are the same, but the direction of flow is opposite, and that direction is always determined by context: are you providing values (spread) or receiving them (rest)? Train yourself to ask that question whenever you see ..., and the two will never feel confusing again.

You're not alone. this is one of those concepts that feels confusing at first, but once it clicks, you'll wonder why it ever confused you. Let's fix that today.

In simple words : The keyword this refers to the object that is currently calling the function.

“this = who is calling the function”

Once you understand this idea, most of the confusion disappears.

1. What Does this Represent?

The value of this depends on how a function is called, not where it is written.

this is the object that called the function. That's it. Not where the function was defined, not what the function does, purely who ran it. Every confusing behavior of this traces back to this single idea.

Basic Example :

function show() {
  console.log(this);
}

show(); // global object

Think of it like the word "home." If you ask Ravi where home is, he'll say Mumbai. Ask Priya the same question and she'll say Delhi. The word "home" is the same, but what it points to depends entirely on who's asking. this works the same way : it's a pointer whose value depends on the context of the call.

2. this in the Global Context

When you write code at the top level : outside any function or object, this points to the global object. In a browser, that's window. In Node.js, it's global.

console.log(this);             // Window { ... } in a browser
console.log(this === window);  // true

You can think of the global context as JavaScript's default home. When no specific object is making the call, this falls back here automatically.

One thing worth knowing early: in strict mode ('use strict'), this inside a regular function becomes undefined instead of pointing to the global object. This is a deliberate safety feature to stop you from accidentally creating or modifying global variables when you didn't intend to. You'll encounter strict mode often in modern JavaScript, so it's good to keep this in the back of your mind.

3. this Inside Objects

This is where this stops being abstract and starts being genuinely useful. When a function is a method on an object and you call it through that object, this points to the object itself.

const person = {
  name: 'Arjun',
  greet: function() {
    // `this` is `person`, because person is the one calling greet()
    console.log('Hello, I am ' + this.name);
  }
};

person.greet(); // Hello, I am Arjun

Here's a practical trick to always get this right: look at what's to the left of the dot at the call site. Whatever object you see there is what this will be inside the function. person.greet(), person is to the left, so this is person.

4. this Inside Functions

Here's where most people hit their first real wall with this, so let's walk through it carefully.

If you take a method off an object and call it as a plain, standalone function, it loses its context. There's no longer an object to the left of the dot, so this reverts to the global object (or undefined in strict mode).

js

const person = {
  name: 'Priya',
  greet: function() {
    console.log('Hello, I am ' + this.name);
  }
};

const sayHello = person.greet;  // detached — just a reference to the function

sayHello();  // Hello, I am undefined  ← `this` is now window, not person

When you assigned person.greet to sayHello, you only copied the function reference, you didn't carry the object along with it. So when sayHello() runs, JavaScript looks for a caller to the left of the dot, finds nothing, and defaults to global. Since window.name doesn't exist in your code, you get undefined.

this inside Arrow Functions :

Arrow functions are the clean solution to this. Unlike regular functions, an arrow function doesn't have its own this at all — it simply inherits this from wherever it was written (its surrounding scope). This means it locks in the value of this at definition time, not call time.

const user = {
  name: 'Kiran',
  sayHi: function() {
    // Arrow function inherits `this` from sayHi(), where `this` is `user`
    setTimeout(() => {
      console.log('Hi, ' + this.name);  // Hi, Kiran ✓
    }, 500);
  }
};

user.sayHi();

The arrow function inside setTimeout looks outward to sayHi()'s scope to find this, and since sayHi was called as user.sayHi(), this there is user. Problem solved.

5. How the Calling Context Changes this

JavaScript gives you three built-in methods : call(), apply(), and bind() , to take manual control of this. Think of them as tools for saying "run this function, but pretend this specific object called it."

call() invokes the function immediately with a this you choose:

function introduce() {
  console.log('Hi, I am ' + this.name);
}

const user1 = { name: 'Ravi' };
const user2 = { name: 'Meera' };

introduce.call(user1);  // Hi, I am Ravi
introduce.call(user2);  // Hi, I am Meera

apply() does exactly the same thing, but you pass any extra arguments as an array rather than individually. Functionally, call and apply are nearly identical, the only difference is that syntax detail.

bind() is different in one important way: instead of calling the function immediately, it returns a new function that is permanently locked to the this you specify, no matter how or where it gets called later.

function introduce() {
  console.log('Hi, I am ' + this.name);
}

const greetAsRavi = introduce.bind({ name: 'Ravi' });

greetAsRavi();          // Hi, I am Ravi — always, no matter what
greetAsRavi.call({ name: 'Someone Else' });  // Still: Hi, I am Ravi

bind() is especially valuable when you're passing a method as a callback, situations where you know the function will lose its context. Instead of relying on arrow functions or workarounds, you can just bind it upfront and trust it'll always have the right this.

Conclusion

At its core, this comes down to one question you should ask every time you see it: who is calling this function right now? Follow the dot at the call site, trace the caller, and this almost always makes perfect sense. Global code defaults to the global object, object methods point back to the object, detached functions lose their context, and arrow functions simply inherit this from wherever they were written. When you need full control, call, apply, and bind let you set the caller yourself.

What makes this feel tricky at first is that the same function can behave differently depending on how it's invoked, not how it's written. That flexibility is actually what makes this so powerful, one reusable function can work correctly across many different objects just by calling it the right way.

While objects and arrays are powerful, they have limitations when it comes to handling key-value pairs and unique data. That’s where Map and Set come in—they provide cleaner, more efficient ways to manage data.

They're not replacements for objects and arrays, they're specialized tools that do certain jobs significantly better.

This article will show you exactly what those jobs are.

1. What Map Is ?

A Map is a collection of key-value pairs, just like an object.

The critical difference: Map accepts any value as a key. Numbers, objects, booleans, even other Maps. Objects only support strings and symbols as keys.

Creating and using a Map:

let userRoles = new Map();

userRoles.set("priya", "admin");
userRoles.set("rahul", "editor");
userRoles.set("ananya", "viewer");

console.log(userRoles.get("priya"));   // "admin"
console.log(userRoles.has("rahul"));   // true
console.log(userRoles.size);           // 3

userRoles.delete("ananya");
console.log(userRoles.size);           // 2

Notice the clean API : .set(), .get(), .has(), .delete(), .size. Everything is explicit and purpose-built, unlike objects where you use obj.key, delete obj.key, and Object.keys(obj).length.

2. What Set Is ?

A Set is a collection of unique values. Add the same value twice, it only appears once. That's the defining characteristic, and it's the whole reason Set exists.

let tags = new Set();

tags.add("javascript");
tags.add("frontend");
tags.add("javascript");  // duplicate — silently ignored
tags.add("es6");

console.log(tags.size);  // 3 — not 4
console.log(tags);       // Set { "javascript", "frontend", "es6" }

No error on duplicates. No fuss. They're just ignored.

Common Set operations:

let skills = new Set(["html", "css", "javascript", "css", "html"]);

console.log(skills.size);              // 3 — duplicates removed automatically
console.log(skills.has("javascript")); // true
console.log(skills.has("python"));     // false

skills.add("react");
skills.delete("html");

console.log([...skills]);  // ["css", "javascript", "react"]

The most practical use : removing duplicates from an array:

let rawTags = ["javascript", "css", "javascript", "react", "css", "html"];

let uniqueTags = [...new Set(rawTags)];

console.log(uniqueTags);
// ["javascript", "css", "react", "html"]

One line. No loops, no filters, no manual checking. Create a Set (duplicates removed automatically), spread it back into an array.

Iterating a Set:

let categories = new Set(["books", "electronics", "clothing"]);

for (let category of categories) {
  console.log(category);
}
// books
// electronics
// clothing

3. Map vs Object

Both store key-value pairs. Here's where they diverge in ways that actually matter:

Key types:

// Object — keys are always strings (or symbols)
let obj = {};
obj[1] = "one";
obj[true] = "yes";

console.log(Object.keys(obj));  // ["1", "true"] — converted to strings

// Map — keys keep their actual type
let map = new Map();
map.set(1, "one");
map.set(true, "yes");

console.log([...map.keys()]);  // [1, true] — kept as number and boolean

Size:

let obj = { a: 1, b: 2, c: 3 };
let map = new Map([["a", 1], ["b", 2], ["c", 3]]);

// Object — no built-in size
console.log(Object.keys(obj).length);  // 3 — manual calculation

// Map — built-in
console.log(map.size);  // 3 — direct property

Iteration:

// Object — needs Object.entries(), not directly iterable
for (let [key, value] of Object.entries(obj)) {
  console.log(key, value);
}

// Map — directly iterable
for (let [key, value] of map) {
  console.log(key, value);
}

Prototype pollution risk:

Plain objects inherit from Object.prototype. This means they come with built-in properties like toString, hasOwnProperty, and constructor. These can cause subtle bugs if you're not careful with key names:

let permissions = {};
permissions["admin"] = true;
permissions["toString"] = true;  // shadows Object.prototype.toString

// Now toString is broken on this object
console.log(permissions.toString());  // "true" — not the function anymore

Map has no such issue. It has no inherited prototype properties that could conflict with your data.

Side-by-side comparison:

4. Set vs Array

Both hold collections of values. The difference is purpose, arrays are ordered lists that allow duplicates; Sets are collections that guarantee uniqueness.

Duplicate behavior:

let arr = [1, 2, 2, 3, 3, 3];
console.log(arr.length);  // 6 — keeps duplicates

let set = new Set([1, 2, 2, 3, 3, 3]);
console.log(set.size);    // 3 — removes duplicates

Membership checking:

let arr = ["apple", "banana", "mango"];
let set = new Set(["apple", "banana", "mango"]);

// Array — scans the whole array O(n)
console.log(arr.includes("mango"));  // true

// Set — direct lookup O(1)
console.log(set.has("mango"));       // true

For large collections, this performance difference is significant. If you're frequently checking whether a value exists, Set is dramatically faster than an array.

What arrays can do that Set can't:

let arr = [1, 2, 3, 4, 5];

// Index access
console.log(arr[2]);  // 3

// map, filter, reduce
let doubled = arr.map(x => x * 2);

// Duplicates (when you want them)
let repeated = [1, 1, 2, 2, 3];

Sets don't support index access set[0] gives you undefined. They also don't have map, filter, or reduce directly. For those operations, convert to an array first:

let set = new Set([1, 2, 3, 4, 5]);
let doubled = [...set].map(x => x * 2);
// [2, 4, 6, 8, 10]

Side-by-side comparison:

5. When to Use Map and Set

The clearest signal for reaching for Map or Set is when you find yourself working around a limitation of plain objects or arrays. Use Map when: You need non-string keys, especially when you want to associate data with DOM elements or objects:

let elementData = new Map();

let button = document.getElementById("submit");
let input  = document.getElementById("email");

elementData.set(button, { clickCount: 0, lastClicked: null });
elementData.set(input,  { errorCount: 0, lastError: null });

You need to know the size directly, or iterate keys and values frequently:

let config = new Map([
  ["theme", "dark"],
  ["language", "en"],
  ["timezone", "IST"]
]);

console.log(`${config.size} settings loaded`);

for (let [key, value] of config) {
  applyConfig(key, value);
}

The data is highly dynamic, keys being added and removed frequently:

let activeSessions = new Map();

function login(userId, token) {
  activeSessions.set(userId, { token, loginTime: Date.now() });
}

function logout(userId) {
  activeSessions.delete(userId);
}

function isActive(userId) {
  return activeSessions.has(userId);
}

Use Set when:

You're collecting values and don't want duplicates:

// Collecting unique error codes from multiple API calls
let errorCodes = new Set();

responses.forEach(response => {
  if (response.error) errorCodes.add(response.error.code);
});

console.log([...errorCodes]);  // only unique error codes

You need fast membership checking over a large list:

// Blocklist lookup — Set is much faster than array for this
let blockedUsers = new Set(["user_42", "user_99", "user_187"]);

function canPost(userId) {
  return !blockedUsers.has(userId);
}

You want to find the union, intersection, or difference of two collections:

let setA = new Set([1, 2, 3, 4]);
let setB = new Set([3, 4, 5, 6]);

// Union — all values from both
let union = new Set([...setA, ...setB]);
// Set { 1, 2, 3, 4, 5, 6 }

// Intersection — only values in both
let intersection = new Set([...setA].filter(x => setB.has(x)));
// Set { 3, 4 }

// Difference — values in A but not B
let difference = new Set([...setA].filter(x => !setB.has(x)));
// Set { 1, 2 }

These patterns come up in real features, finding common friends, shared tags, users who belong to one group but not another.

Conclusion

Map and Set aren't replacements for objects and arrays. They're specialized tools that solve specific problems cleanly.

Reach for Map when your keys aren't strings, when you need reliable size and iteration, or when data is dynamic enough that an object's prototype quirks could be a problem.

Reach for Set when uniqueness matters, when you need fast membership checking, or when you want to perform set operations like union and intersection cleanly.