In this blog, we’ll understand what REST APIs actually are, what resources mean in REST architecture, how HTTP methods work, what status codes represent, and how to design cleaner routes in Express.js using proper REST principles.

What REST API Actually Means

REST stands for Representational State Transfer. The name sounds complicated initially, but in practice REST APIs are mainly about designing backend routes in a clean and predictable way.
A REST API allows clients and servers to communicate using HTTP requests. The client sends a request, the server processes it, and then the server sends back a response.

For example:

GET /users

This request may ask the server to return all users.

Similarly:

POST /users

This request may ask the server to create a new user.
The main idea behind REST is keeping routes structured around resources instead of random route naming.

Understanding Resources in REST APIs

Resources are one of the most important concepts in REST architecture.
A resource simply means the main data entity your API is working with.
Examples:

• users

• products

• posts

• orders

• comments

Suppose you are building a social media backend. In that case, users and posts may become resources.

Instead of creating routes like:

/getAllUsers

REST principles usually prefer cleaner resource-based routes like:

/users

This makes APIs easier to understand and maintain later.

Understanding HTTP Methods

REST APIs heavily use HTTP methods for defining actions. Instead of creating separate route names for every operation, REST combines routes with HTTP methods to describe behavior.
The four most common methods are:

• GET

• POST

• PUT

• DELETE

These methods directly map to CRUD operations.

GET Request

GET is used for fetching data from the server.

Example:

GET /users

This may return all users.

Another example:

GET /users/101

This may return a specific user having ID 101.

In Express.js:

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

GET requests are mainly used whenever the client wants to retrieve data.

POST Request

POST is used for creating new resources.

Example:

POST /users

This may create a new user in the database.
Express example:

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

POST requests usually carry data inside the request body.

PUT Request

PUT is used for updating existing resources.
Example:

PUT /users/101

This may update the user having ID 101.

Express example:

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

PUT requests are commonly used for editing or replacing existing data.

DELETE Request

DELETE is used for removing resources.

Example:

DELETE /users/101

This may delete the user having ID 101.

Express example:

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

This keeps route structures clean because the route remains the same while the HTTP method changes the operation.

Designing Routes Using REST Principles

One major beginner mistake is creating routes like:

/createUser
/deleteUser
/updateUser

While these technically work, REST APIs usually avoid action-based route naming.
Instead, REST focuses on resource-based routes:

/users
/users/:id

The HTTP method itself defines the action.
For example:

GET /users
POST /users
PUT /users/101
DELETE /users/101

This structure keeps APIs predictable and much easier to scale later.

Understanding Status Codes

Whenever the server responds to a request, it also sends a status code. Status codes help the client understand whether the request succeeded or failed.
Some very common status codes are:

• 200 → Success

• 201 → Resource created

• 400 → Bad request

• 404 → Resource not found

• 500 → Internal server error

Express example:

app.get("/users", (req, res) => {
  res.status(200).send("Users fetched");
});

For resource creation:

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

Status codes make backend communication more meaningful because the frontend immediately understands what happened with the request.

Example REST API Structure for Users

A simple REST structure for a users resource may look like this:

GET /users
GET /users/:id
POST /users
PUT /users/:id
DELETE /users/:id

This single structure already covers fetching, creating, updating, and deleting users cleanly using REST conventions.

Why REST APIs Became So Popular

REST APIs became extremely popular because they are simple, predictable, scalable, and easy to understand. Frontend applications, mobile apps, and third-party services can all communicate with backend systems using the same standardized HTTP approach.
REST also keeps route structures clean because developers do not need to invent random naming patterns for every operation. Once someone understands REST conventions, most APIs start feeling naturally readable.

Final Thoughts

REST API design may initially look slightly confusing because terms like resources, routes, methods, and status codes appear together. But at its core, REST is mainly about organizing backend communication in a structured and predictable way.

Instead of building action-based routes, REST focuses on resources and HTTP methods. GET fetches data, POST creates data, PUT updates data, and DELETE removes data. Combined with proper status codes and cleaner route structures, REST APIs become much easier to build, maintain, and scale in real-world backend applications using Express.js.

What URL Parameters Actually Are

URL parameters are dynamic values present directly inside the route path. They are mainly used to identify a specific resource. For example:

/users/101

Here, 101 is usually representing a specific user ID.

Similarly:

/products/55

Here, 55 may represent a specific product. In Express.js, URL parameters are defined using a colon (:). Example:

app.get("/users/:id", (req, res) => {
  res.send("User Route");
});

Here, :id becomes a route parameter.

Accessing URL Parameters in Express.js

Express provides all route parameters inside req.params. Example:

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

  res.send("User fetched");
});

If the request URL is:

/users/101

Output:

{ id: '101' }

You can directly access the value like this:

req.params.id

This is one of the most common patterns used in APIs while fetching specific users, products, posts, orders, or resources from databases. Whenever the value is directly identifying one particular resource, route parameters are usually the better choice because the route itself depends on that value for fetching the correct data.

What Query Parameters Are

Query parameters are different. Instead of being part of the route path itself, query strings appear after a question mark (?) in the URL. They are mainly used for filtering, sorting, searching, pagination, or modifying results. Example:

/products?category=mobile

Here, category=mobile is a query parameter.

Another example:

/products?category=mobile&price=low

Here, multiple query parameters are being passed together. Unlike route parameters, query strings usually do not identify a single specific resource. Instead, they modify how the data should be returned from the server.

Accessing Query Strings in Express.js

Express provides query parameters inside req.query. Example:

app.get("/products", (req, res) => {
  console.log(req.query);

  res.send("Products fetched");
});

If the request URL is:

/products?category=mobile&price=low

Output:

{
  category: 'mobile',
  price: 'low'
}

You can directly access values like this:

req.query.category
req.query.price

This is commonly used in APIs for search filters, sorting options, page numbers, and result customization. Most modern APIs heavily use query parameters whenever users need filtered or customized responses from the server.

Understanding the Core Difference

This is the main thing beginners should properly understand. URL parameters are generally used when the value is required to identify a specific resource. For example:

/users/101

Here, the route itself depends on the user ID because the server needs to know exactly which user is being requested.

On the other hand, query strings are generally optional modifiers or filters. For example:

/products?category=mobile

Here, the route still remains /products. The query parameter is simply modifying or filtering the response. That is the biggest conceptual difference between params and query strings in Express.js applications.

Practical Examples

Suppose you are building a social media backend. Fetching a specific user profile:

/users/101

This should usually use route parameters because the ID identifies one particular user.

Now suppose you are searching posts:

/posts?tag=nodejs

This should usually use query parameters because the tag is filtering results, not identifying one exact resource. Similarly, pagination, sorting, filtering, and searching are usually handled through query strings because they modify the returned data rather than uniquely identifying something.

Combining Params and Query Strings Together

Both can also be used together in real applications. Example:

/users/101/posts?page=2

Here:

• 101 is a route parameter

• page=2 is a query parameter

In Express:

app.get("/users/:id/posts", (req, res) => {
  console.log(req.params.id);
  console.log(req.query.page);

  res.send("Posts fetched");
});

Possible output:

101
2

This type of structure is very common in real-world REST APIs because it allows APIs to identify resources while also customizing or paginating the response at the same time.

When Should You Use Params vs Query?

A very simple way to decide is this. Use route parameters when the value is necessary to identify a specific resource. Use query parameters when the value modifies, filters, searches, sorts, or customizes the response.

For example:

/products/55

Specific product identification.

Whereas:

/products?sort=price

Sorting or filtering products. Once this distinction becomes clear, designing cleaner APIs becomes much easier because the URL structure starts naturally making more sense.

Common Beginner Mistake

One very common beginner mistake is trying to use query parameters for everything. For example:

/users?id=101

While this technically works, most REST API conventions prefer:

/users/101

because the user ID directly identifies a specific resource. Using proper URL structure improves API readability and makes routes easier to understand, maintain, and scale later in larger applications.

Final Thoughts

URL parameters and query strings may initially look very similar because both pass data through the URL, but their purposes are actually quite different. Route parameters are mainly used for identifying resources, whereas query parameters are used for filtering, searching, sorting, pagination, or modifying responses.

Once this distinction becomes clear, designing clean REST APIs in Express.js becomes much easier because you’ll naturally know which type of data belongs in the route path and which belongs inside query strings.

In this blog, we’ll understand what authentication actually means, what JWT is, how JWT-based login works, the structure of a JWT token, how tokens are sent with requests, and how protected routes work in Node.js applications.

What Authentication Actually Means

Authentication simply means verifying whether a user is genuinely who they claim to be.

For example, when you enter your email and password on a website, the backend checks whether those credentials are correct or not. If they are correct, the server identifies you as a valid user and allows access to protected resources.
Without authentication, applications would have no proper way to differentiate between users. Anyone could access anyone’s private information, which would obviously become a huge security problem.

Why Authentication is Required

Imagine platforms like Instagram, Netflix, or Gmail without authentication. Every user’s private data would become publicly accessible. Authentication exists to prevent that situation.
Applications need a way to:

• Identify users

• Verify login credentials

• Protect private routes

• Restrict unauthorized access

This is where token-based authentication systems like JWT became extremely popular.

What Exactly is JWT?

JWT stands for JSON Web Token.
It is a token-based authentication mechanism where the server generates a token after successful login and sends that token to the client. The client then sends the same token with future requests to prove identity.
Instead of storing login sessions on the server side continuously, JWT allows applications to verify users using tokens themselves. This is why JWT authentication is often called stateless authentication because the server does not need to store active login sessions separately for every user.

Understanding Stateless Authentication

In traditional session-based authentication, the server stores user session information internally. Every time the client makes a request, the server checks its stored session data to identify the user.
JWT works differently.
Here, the token itself contains the required user-related information. The client stores the token and sends it along with requests. The server verifies the token and identifies the user from it.
This makes JWT authentication lightweight and scalable for modern APIs and frontend-backend architectures.

Structure of a JWT

A JWT mainly contains three parts:

• Header

• Payload

• Signature

These three parts are separated using dots.
A JWT looks something like this:

xxxxx.yyyyy.zzzzz

Each part has its own purpose.

Header

The header contains information about the token type and signing algorithm being used.
A very simplified example:

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

This tells the server what algorithm was used while generating the token.

Payload

The payload contains actual user-related information.
For example:

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

This data is often called claims. Usually, applications store user IDs, emails, or roles inside the payload.

Signature

The signature is responsible for verifying whether the token was modified or not. It is generated using a secret key on the server side.
You do not need to go deep into cryptography initially. The important thing to understand is that the signature helps maintain token integrity and prevents tampering.

Login Flow Using JWT

Now let’s understand the complete login flow at a high level.
When the user logs in:

• Client sends email and password

• Server verifies credentials

• If credentials are correct, server generates JWT

• Token gets sent back to the client

• Client stores the token

• Client sends the token with future requests

This token becomes the user’s identity proof for protected API access.

Generating JWT in Node.js

To generate JWT in Node.js, applications commonly use the jsonwebtoken package.
Example:

const jwt = require("jsonwebtoken");

const token = jwt.sign(
  { id: 1, email: "user@gmail.com" },
  "secretkey",
  { expiresIn: "1h" }
);

console.log(token);

Here:

• jwt.sign() creates the token

• Payload contains user data

• "secretkey" is used for signature generation

• expiresIn defines token expiry time

After generation, this token is usually sent back to the frontend.

Sending Token with Requests

Once the client receives the token, it sends the token with future API requests.
Usually, the token is sent inside request headers.
Example:

Authorization: Bearer your_jwt_token

Whenever the backend receives a protected request, it checks whether the token is valid or not before allowing access.

Protecting Routes Using JWT

Now let’s see a very simple protected route example.

const jwt = require("jsonwebtoken");

function verifyToken(req, res, next) {
  const token = req.headers.authorization;

  if (!token) {
    return res.send("Access denied");
  }

  try {
    const verified = jwt.verify(token, "secretkey");
    req.user = verified;
    next();
  } catch {
    res.send("Invalid token");
  }
}

Here:

• jwt.verify() checks token validity

• If token is valid, request continues

• If token is invalid, access gets denied

This is how protected routes work in JWT authentication systems.

Why JWT Became So Popular

JWT became extremely popular because modern applications often have separate frontend and backend systems. Mobile apps, React frontends, APIs, and microservices all needed a lightweight authentication mechanism that worked well across different platforms.
Since JWT is stateless, scalable, and easy to send with requests, it became a common choice for API-based authentication systems.

Final Thoughts

JWT authentication may initially look slightly complicated because terms like tokens, payloads, headers, signatures, and protected routes appear together. But at its core, the flow is actually very straightforward.
The server verifies user credentials, generates a token, sends it to the client, and later verifies that same token whenever protected resources are accessed.
That is the core idea behind JWT authentication.
Once this flow becomes clear, understanding authentication systems in Node.js becomes much easier because almost every modern backend application eventually uses some form of token-based authentication internally.

Hope it helps!.

What Actually Makes Node.js Fast?

One important thing to understand is that Node.js is not fast because JavaScript itself suddenly became magically powerful. The real reason behind Node.js performance is its execution model.
Traditional backend systems often spend a lot of time waiting. For example, while reading files, querying databases, or calling APIs, the server may sit idle waiting for responses. If multiple users arrive together, these waiting operations can slow the entire system down.Node.js works differently.
Instead of waiting for one operation to finish before handling the next request, Node.js performs slow tasks asynchronously and continues processing other incoming requests. This allows the server to remain responsive even under heavy traffic.

Understanding Non-Blocking I/O

One of the biggest reasons behind Node.js speed is non-blocking I/O.

I/O simply refers to input and output operations like:

• File handling

• Database communication

• API requests

• Network operations

In blocking systems, the server waits for these operations to finish completely before moving ahead. In non-blocking systems like Node.js, the operation starts in the background while the server continues handling other tasks. For example:

const fs = require("fs");

console.log("Reading started");

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

console.log("Other requests continue");

Possible output:

Reading started
Other requests continue
File content here

Notice what happened here. Node.js did not stop execution while reading the file. Instead, it started the operation in the background and continued executing the remaining code immediately. Once the file reading completed, the callback executed later.
This is exactly what makes Node.js highly efficient for applications handling many simultaneous users.

Event-Driven Architecture in Node.js

Another major reason behind Node.js performance is its event-driven architecture.
Node.js works around events and callbacks. Whenever an operation completes, an event gets triggered and the corresponding callback executes. Instead of continuously waiting for operations, Node.js reacts whenever something becomes ready. For example:

const EventEmitter = require("events");

const emitter = new EventEmitter();

emitter.on("message", () => {
  console.log("Event received");
});

emitter.emit("message");

Output:

Event received

This event-driven flow helps Node.js efficiently manage many activities together without blocking the execution flow unnecessarily.

Understanding the Single-Threaded Model

One thing that surprises many beginners is that Node.js mainly uses a single thread for JavaScript execution.
Initially, this sounds like a weakness because people often assume multiple threads automatically mean better performance. But Node.js uses its single-threaded model very smartly.
Instead of creating many heavy threads for every incoming request, Node.js handles requests asynchronously. Slow operations get delegated to background system workers while the main JavaScript thread continues processing other requests.
This reduces thread management overhead and helps Node.js stay lightweight.

Concurrency vs Parallelism

A lot of people confuse concurrency with parallelism.
Parallelism means multiple tasks are literally executing at the same exact time using multiple CPU cores or threads. Concurrency means multiple tasks are progressing efficiently together without necessarily executing simultaneously.

Node.js mainly focuses on concurrency.

While one operation waits for a database response or file read, Node.js continues handling other incoming requests instead of sitting idle. This creates excellent responsiveness for I/O-heavy applications.

Blocking vs Non-Blocking Request Handling

Let’s understand the difference practically.

In blocking systems, suppose one request takes 5 seconds to fetch data from a database. During that time, the server may remain occupied waiting for that operation to finish before efficiently handling other requests.
In Node.js, that database operation starts asynchronously in the background while the server continues handling other incoming users immediately.
This difference becomes extremely important when thousands of users interact with the application together. Node.js avoids unnecessary waiting and keeps resource utilization efficient.

Where Node.js Performs Best

Node.js performs especially well in applications involving continuous I/O operations and real-time communication.

Some common examples include:

• REST APIs

• Chat applications

• Streaming platforms

• Notification systems

• Real-time dashboards

• Collaborative tools

• Gaming backends

These systems constantly communicate with databases, APIs, sockets, or files, and Node.js handles such asynchronous workloads very efficiently.

Real-World Companies Using Node.js

Many large companies adopted Node.js because of its scalability and fast request-handling capabilities.
Some popular companies using Node.js include:

• Netflix

• PayPal

• LinkedIn

• Uber

• Walmart

These companies needed systems capable of handling massive concurrent traffic efficiently, and Node.js became a strong choice for many of those use cases.

Why Developers Loved Node.js

Another major reason developers loved Node.js was the ability to use JavaScript across the full stack. Earlier, frontend and backend development often required different languages. With Node.js, developers could use JavaScript both inside the browser and on the server side.
This improved development speed, reduced context switching, and simplified full-stack development workflows significantly.

Final Thoughts

Node.js became extremely popular because it solved a very important problem efficiently: handling large numbers of concurrent requests without wasting resources waiting unnecessarily.

Its non-blocking I/O model, event-driven architecture, lightweight execution flow, and asynchronous handling system made it perfect for fast modern web applications. Instead of relying heavily on multiple threads, Node.js focused on efficient concurrency and smart request handling.

That is exactly why Node.js performs exceptionally well for APIs, real-time systems, streaming platforms, and applications where responsiveness and scalability matter heavily.

Node.js completely changed how developers looked at JavaScript because now the same language could be used both on the frontend and backend. Before Node.js existed, JavaScript was mostly restricted to browsers. But after Node.js arrived, developers could suddenly build full backend applications using JavaScript itself.

What Exactly is Node.js?

Node.js is a JavaScript runtime environment that allows JavaScript code to run outside the browser.
A lot of beginners initially confuse JavaScript and Node.js as the same thing, but both are different. JavaScript is the programming language itself, whereas Node.js is an environment that executes JavaScript on the server side.
For example:

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

This code can directly run using Node.js in the terminal without needing any browser. That is the biggest difference Node.js introduced.

Why JavaScript Was Originally Browser-Only

When JavaScript was first created, its purpose was to make websites interactive inside browsers. Browsers provided features like the DOM, buttons, forms, and events, and JavaScript worked around those browser features.

For example:

document.getElementById("btn").addEventListener("click", () => {
  console.log("Button clicked");
});

This code depends on browser APIs. Outside browsers, JavaScript initially had no proper environment to execute in. That meant JavaScript could not directly create servers, handle databases, or process backend logic.

How Node.js Changed Everything

Node.js solved this problem by providing a runtime environment for JavaScript outside the browser. Instead of browser-related features, Node.js provides backend capabilities like file handling, networking, HTTP servers, and process management.
For example:

const http = require("http");

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

server.listen(3000);

This small code creates a backend server using JavaScript itself. Before Node.js, JavaScript was never really used for this type of server-side work.

Understanding the V8 Engine

One important thing behind Node.js is the V8 engine.

V8 is Google Chrome’s JavaScript engine responsible for compiling and executing JavaScript code efficiently. Node.js internally uses this same engine to run JavaScript outside the browser.
So whenever you run a JavaScript file using Node.js, the V8 engine executes that code on your machine.

JavaScript Runtime vs Programming Language

This is another important concept beginners often confuse.
JavaScript itself is only the language. Things like variables, loops, functions, arrays, and objects belong to JavaScript.But features like file handling, HTTP servers, and timers come from the runtime environment.
In browsers, the runtime is the browser itself. On the backend side, the runtime becomes Node.js.

Event-Driven Architecture in Node.js

One major reason developers adopted Node.js heavily was its event-driven and non-blocking architecture.
Traditional backend systems often blocked execution while waiting for slow operations like database responses or file reads. Node.js handles things differently. It performs slow operations asynchronously and continues handling other tasks instead of waiting unnecessarily.
For example:

const fs = require("fs");

console.log("Reading started");

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

console.log("Other work continues");

Possible output:

Reading started
Other work continues
File content here

Here, Node.js does not stop execution while reading the file. This non-blocking behavior became one of the biggest reasons behind Node.js adoption.

Node.js vs Traditional Backend Technologies

Before Node.js became popular, backend development was heavily dominated by technologies like PHP and Java. Many traditional systems created separate threads for handling different client requests.
Node.js became popular because it handled concurrency differently using asynchronous execution and an event-driven architecture. Instead of creating many heavy threads, Node.js efficiently handled multiple requests while staying lightweight.
This made Node.js especially useful for APIs, chat applications, streaming services, and real-time systems.

Real-World Use Cases of Node.js

Today Node.js is used almost everywhere in backend development. It is commonly used for REST APIs, real-time chat applications, streaming platforms, authentication systems, collaborative tools, and notification services.
One of the biggest reasons developers loved Node.js was that the same language could now be used for both frontend and backend development. Earlier, developers often had to learn JavaScript for frontend and another language for backend work. Node.js simplified that workflow significantly.

Final Thoughts

Node.js was a major turning point in web development because it allowed JavaScript to move beyond browsers and become a serious backend technology. Instead of being limited to frontend interactions, JavaScript could now create servers, handle APIs, process databases, and build scalable backend applications.

At its core, Node.js is simply a runtime environment that executes JavaScript outside the browser using the V8 engine. But its real impact came from its asynchronous event-driven architecture and the ability to use one language across the entire application stack.

What Exactly is Node.js?

Before installing Node.js, it is important to understand what it actually is. Node.js is a JavaScript runtime environment that allows us to run JavaScript outside the browser. Normally, JavaScript executes inside browsers like Chrome or Firefox, but Node.js allows JavaScript to run directly on your machine.
This is what made JavaScript extremely powerful for backend development because now developers could use the same language for both frontend and backend applications. Node.js internally uses Google Chrome’s V8 JavaScript engine for executing JavaScript code very efficiently.

Installing Node.js

Installing Node.js is fairly simple. You just need to visit the official Node.js website and download the installer according to your operating system. Once the installer downloads, you can proceed with the default installation steps normally without changing much.
While installing, Node.js also installs npm automatically. npm stands for
Node Package Manager and it helps us install libraries and packages later while building applications.
After the installation completes, the next step is verifying whether Node.js was installed correctly or not.

Checking Node.js Installation from Terminal

To verify the installation, open your terminal or command prompt and run:

node -v

If Node.js was installed correctly, you’ll see a version number printed on the screen. Something like:

v22.0.0

You can also check the npm version using:

npm -v

Again, this should print the installed npm version.
If both commands work successfully, then your Node.js setup is ready and you can start executing JavaScript using Node.js.

Understanding the Node REPL

Before creating our first file, there’s one important thing worth understanding called the REPL.
REPL stands for Read, Evaluate, Print, Loop.
It is basically an interactive environment where Node.js executes JavaScript code line by line directly from the terminal. This becomes very useful for quickly testing small snippets without creating separate files every time.

To start the Node REPL, simply type:

node

After running this command, you’ll enter the Node.js interactive environment.
Now you can directly execute JavaScript like this:

console.log("Hello from REPL");

Output:

Hello from REPL

You can even perform calculations:

10 + 20

Output:

30

The REPL is mainly useful for testing things quickly while learning or debugging. To exit the REPL, you can type:

.exit

or simply press Ctrl + C twice.

Creating Your First JavaScript File

Now let’s create our very first Node.js file.
Create a folder anywhere on your system and inside that folder create a file named:

app.js

Inside this file, write:

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

This is a very basic JavaScript file, but now instead of running it inside a browser, we’ll execute it using Node.js directly from the terminal.

Running Your First Node.js Script

Now open the terminal inside the same folder where your file exists and run:

node app.js

Output:

Hello World from Node.js

This is officially your first Node.js application running successfully.
What actually happened here is that Node.js took your JavaScript file, passed it to the V8 engine, executed the code, and displayed the output in the terminal.

Understanding the Execution Flow

Whenever you run:

node app.js

a simple flow happens internally.

• Node.js reads the file

• The V8 engine compiles the JavaScript

• The code gets executed

• Output appears in the terminal

This is the basic execution flow behind every Node.js application, whether it is a tiny script or a massive backend server.

Writing Your First Hello World Server

Now let’s create a very small server using Node.js. This is usually the point where people start feeling excited because now JavaScript is actually creating backend servers.
Replace the previous code inside app.js with this:

const http = require("http");

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

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

Now run the file again:

node app.js

Output:

Server running on port 3000

At this point, your Node.js server is actually running.
Now open your browser and visit:

http://localhost:3000

You’ll see:

Hello World from Server

This is your first backend server running successfully using Node.js.

Understanding What Happened in the Server Code

The http module used here is a built-in Node.js module that helps create servers. We used createServer() to create a server instance and passed a callback function that executes whenever a client sends a request to the server.
Inside that callback, res.end() sends the response back to the client. Then server.listen() starts the server on port 3000 so the application becomes accessible through the browser.
Even though the code is small, this is the starting point for almost every backend application built using Node.js.

Final Thoughts

Setting up Node.js and running the first application is an important step because this is where backend development with JavaScript actually begins. Initially, terms like runtime, REPL, server, and terminal may feel slightly unfamiliar, but once you execute your first few programs, things start becoming much more comfortable.
In this blog, we installed Node.js, verified the installation using terminal commands, understood the REPL environment, created our first JavaScript file, executed it using Node.js, and finally built a small Hello World server. These may look like simple steps, but they form the foundation for everything you’ll build later using Node.js, whether it’s APIs, authentication systems, databases, or full backend applications.

This is exactly where concepts like the event loop, asynchronous operations, and background workers become important. A lot of beginners initially think Node.js somehow executes everything in parallel inside JavaScript itself, but that is not actually what happens. Node.js handles concurrency very smartly, and understanding this flow is extremely important if you want to properly understand backend development using Node.js.

In this blog, we’ll understand how Node.js manages multiple requests using a single thread, what role the event loop plays, how slow tasks get delegated to background workers, and why Node.js scales so well for I/O-heavy applications.

Understanding Single-Threaded Nature of Node.js

When people say Node.js is single-threaded, they are mainly referring to JavaScript execution. JavaScript inside Node.js runs on a single main thread, which means one piece of JavaScript code executes at a time. If one function is currently running, another function has to wait until the current execution completes. For example:

function task1() {
  console.log("Task 1 started");
}

function task2() {
  console.log("Task 2 started");
}

task1();
task2();

& Output:

Task 1 started
Task 2 started

Everything executes one after another because JavaScript uses a single call stack for execution. Initially, this may sound like a limitation because we usually associate single-threaded systems with slow performance. But Node.js works differently because it avoids blocking behavior for slow operations.
This is why understanding only the “single-threaded” part is incomplete. The real power of Node.js comes from how it handles asynchronous operations around that single thread.

Thread vs Process in Simple Terms

A process can be thought of as an independent running application. Inside a process, there can be one or multiple threads. Threads are smaller execution units responsible for performing tasks inside the process.
Traditional backend systems often create multiple threads to handle multiple users simultaneously. Node.js takes a different approach. Instead of creating separate threads for every incoming request, Node.js mainly relies on a single JavaScript thread combined with asynchronous non-blocking execution.
This makes Node.js lightweight because creating too many threads can increase memory usage and context-switching overhead. Node.js tries to avoid that problem by efficiently handling waiting operations in the background instead of keeping multiple threads busy doing nothing.

So How Does Node.js Handle Multiple Requests?

This is where the event loop becomes extremely important.

Suppose multiple users send requests to a Node.js server together. The JavaScript thread starts processing those requests one by one, but whenever a slow operation appears, Node.js does not block the thread waiting for that operation to complete.
Instead, it delegates the slow task to background system workers and immediately continues handling other incoming requests. For example:

const fs = require("fs");

console.log("Request 1 started");

fs.readFile("sample.txt", "utf-8", (err, data) => {
  console.log("File reading completed");
});

console.log("Request 2 started");

Possible output:

Request 1 started
Request 2 started
File reading completed

Notice what happened here. The file reading operation did not block JavaScript execution. Node.js handed over the file operation to the system-level APIs running in the background and immediately continued processing the next request. Once the file operation completed, its callback became ready for execution later.
This is one of the biggest reasons Node.js can keep handling many incoming requests efficiently even while using a single JavaScript thread.

Role of the Event Loop in Concurrency

The event loop acts like a coordinator between JavaScript execution and completed asynchronous operations. Its job is to continuously check whether the call stack is empty and whether any completed async callbacks are waiting.
If the stack becomes free, the event loop pushes ready callbacks into execution.
This allows Node.js to keep moving between multiple tasks efficiently without blocking the main thread unnecessarily. The event loop itself does not magically execute multiple JavaScript functions together simultaneously. Instead, it smartly schedules completed operations for execution whenever JavaScript becomes free.

This is an important point because Node.js mainly achieves concurrency, not true parallel JavaScript execution on the main thread.

Concurrency vs Parallelism

A lot of people confuse concurrency with parallelism, but both are different things.
Parallelism means multiple tasks are literally executing at the exact same moment on multiple CPU cores or threads. Concurrency means multiple tasks are progressing efficiently together without necessarily executing simultaneously.

Node.js mainly focuses on concurrency. It quickly switches between operations and avoids unnecessary waiting. Slow operations continue in the background while JavaScript keeps processing other requests.
This creates the feeling that many things are happening together even though the main JavaScript execution itself is still single-threaded.

Delegating Tasks to Background Workers

One important thing to understand is that Node.js does not perform slow I/O operations directly using the JavaScript thread. Operations like file reading, database communication, network requests, DNS lookups, and some cryptographic operations are delegated to underlying system APIs and worker threads managed internally by Node.js.

JavaScript itself only registers callbacks and continues execution. For example:

const crypto = require("crypto");

console.log("Hashing started");

crypto.pbkdf2("password", "salt", 100000, 64, "sha512", () => {
  console.log("Hash generated");
});

console.log("Handling other requests");

& possible output:

Hashing started
Handling other requests
Hash generated

While the heavy hashing operation was happening in the background, JavaScript continued handling other work. This delegation system is extremely important for maintaining responsiveness under high traffic.

Why Node.js Scales So Well

The reason Node.js scales efficiently is because it spends very little time waiting idly. In traditional blocking systems, a thread may sit inactive while waiting for database responses, file reads, or API results. If many users arrive together, a large number of threads may become occupied simply waiting.

Node.js avoids this issue by using asynchronous non-blocking execution. Instead of waiting for one request to finish completely before handling others, Node.js keeps moving ahead with other incoming work while slow operations continue in the background.
This leads to better resource utilization and allows Node.js servers to handle a large number of concurrent users efficiently without consuming massive system resources.
That is exactly why Node.js became extremely popular for APIs, real-time applications, streaming platforms, chat systems, and notification services where large amounts of I/O operations happen continuously.

A Small Request Flow Example

Suppose three users send requests almost together:

• User 1 requests file data

• User 2 requests database data

• User 3 requests API response

Node.js starts each request, delegates the slow operations to background handlers, and continues accepting more incoming requests instead of waiting for one operation to finish first.
As soon as any operation completes, its callback becomes ready, and the event loop schedules it for execution whenever the call stack becomes available.
This is how one JavaScript thread efficiently handles many client requests together without becoming blocked.

Final Thoughts

Initially, hearing that Node.js is single-threaded can make it sound weak compared to systems using multiple threads. But the real strength of Node.js comes from how efficiently it handles asynchronous non-blocking operations around that single thread.
Instead of wasting resources waiting for slow operations to complete, Node.js delegates those operations to background workers and keeps the main thread free for handling other incoming requests. The event loop continuously coordinates completed operations and schedules their execution whenever JavaScript becomes available.

This combination of asynchronous execution, background delegation, and efficient concurrency is what allows Node.js to handle multiple requests so effectively while still using a single JavaScript thread.

This concept is actually one of the biggest reasons why Node.js became so popular for backend development. Once you understand blocking vs non-blocking execution properly, a lot of other concepts like async programming, callbacks, promises, APIs, and even the event loop start making much more sense. In this blog, we’ll understand what blocking and non-blocking code actually means, why blocking operations can slow down servers, how Node.js handles async tasks internally at a high level, and why non-blocking behavior helps Node.js applications stay scalable.

What Blocking Code Actually Means

Blocking code simply means that one operation blocks the execution of everything that comes after it until it finishes completely. JavaScript executes code line by line, and if one particular operation takes a lot of time, the remaining code has to wait there patiently until that operation gets completed. During this waiting period, nothing else moves ahead because the current task is still occupying the execution flow. A simple example can make this much clearer.

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

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

  console.log("Slow task completed");
}

function nextTask() {
  console.log("Next task executed");
}

slowTask();
nextTask();

and output after 5 seconds:

Slow task completed
Next task executed

Here, the second function could not execute immediately because the first function blocked the execution for 5 seconds. JavaScript was completely busy with the current task and could not move ahead until it finished. This type of behavior is called blocking execution because one operation blocks everything behind it.

Why Blocking Code Becomes a Problem on Servers

In small programs, blocking code may not feel like a huge issue. But on backend servers, this can become a serious performance problem very quickly. Imagine a server receiving requests from multiple users together. If one user triggers a slow operation and the server blocks during that time, then other users also get stuck waiting unnecessarily.

Suppose one user requests a large file from the database and reading that file takes several seconds. If the server uses blocking operations, then during those few seconds the server may not efficiently process other incoming requests. This directly affects responsiveness and scalability because users start experiencing delays even for small operations.

This is one of the biggest reasons why backend systems try to avoid blocking behavior as much as possible. Instead of waiting for slow operations to complete, modern systems prefer continuing with other tasks and handling the result later whenever it becomes available.

What Non-Blocking Code Means

Non-blocking code works differently. Instead of waiting for a slow operation to finish completely, Node.js starts that operation in the background and immediately continues executing the remaining code. Once the operation finishes, its callback or result gets handled later. This allows the application to stay responsive instead of getting stuck waiting. For example:

const fs = require("fs");

console.log("Reading file started");

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

console.log("Other operations continue");

Possible output:

Reading file started
Other operations continue
File content here

Notice something important here. The file reading operation did not block the execution flow. Node.js started reading the file in the background and immediately continued executing the remaining code. Once the file reading completed, the callback function executed later with the file data. This is exactly what non-blocking execution means.

How Async Operations Help in Non-Blocking Execution

The reason Node.js achieves non-blocking behavior is because of asynchronous operations. Operations like file handling, database queries, API requests, and timers are generally slow compared to normal JavaScript execution. Instead of making JavaScript wait for them, Node.js delegates these operations to system-level components running in the background.
JavaScript itself does not sit idle waiting for the result. It simply registers the callback function and continues moving ahead with the remaining execution flow. Once the operation completes, the callback becomes ready and eventually gets executed. For example:

console.log("Start");

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

console.log("End");

Output:

Start
End
Timer completed

Here, the timer operation did not stop JavaScript execution for 3 seconds. Node.js handled the timer separately while JavaScript continued executing the remaining lines immediately. Once the timer duration completed, the callback executed later. This is one of the most basic examples of asynchronous non-blocking behavior in Node.js.

Blocking vs Non-Blocking File Handling

File handling is one of the best places to understand the difference between blocking and non-blocking execution because Node.js provides both versions.
First, let’s see blocking file reading.

const fs = require("fs");

console.log("Reading started");

const data = fs.readFileSync("sample.txt", "utf-8");

console.log(data);

console.log("Execution completed");

In this case, Node.js waits completely until the file is fully read. Only after the file reading operation finishes does the remaining code continue execution. This is blocking behavior because the execution flow remains stuck during the file reading process.
Now let’s see the non-blocking version.

const fs = require("fs");

console.log("Reading started");

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

console.log("Execution completed");

Here, Node.js immediately moves ahead after starting the file read operation. The server does not sit idle waiting for the file content. Once the reading finishes, the callback executes later with the data. This is non-blocking behavior and it is much more efficient for backend applications handling multiple users together.

Real World Impact on Server Performance

The difference between blocking and non-blocking code becomes extremely important when traffic increases. A blocking server may spend a lot of time waiting for slow operations to finish, which means fewer requests get processed efficiently during that period. As more users arrive, delays start increasing and performance begins degrading.
Non-blocking systems behave much better in these situations because they do not waste time waiting unnecessarily. While one operation is happening in the background, the server can continue handling other incoming requests. This improves concurrency, responsiveness, and overall scalability.

This is exactly why Node.js became very popular for APIs, chat applications, streaming systems, notification services, and real-time applications where continuous I/O operations happen all the time. Most backend operations involve waiting for something external like databases, APIs, or file systems, and Node.js handles these situations very efficiently using asynchronous non-blocking behavior.

Does Non-Blocking Mean Everything Runs Simultaneously?

One common misconception is that non-blocking means JavaScript executes multiple things together simultaneously. That is not exactly true. JavaScript itself still runs on a single thread. What actually happens is that slow operations are delegated outside the main execution flow, and JavaScript continues handling other work while those operations complete in the background.
So non-blocking does not mean JavaScript suddenly becomes multi-threaded. It simply means JavaScript does not unnecessarily wait for slow operations before continuing execution.

Final Thoughts

Understanding blocking vs non-blocking code is one of the most important steps in learning Node.js properly because this concept directly affects how backend applications perform under load. Blocking operations can slow down servers by forcing the execution flow to wait unnecessarily, whereas non-blocking operations allow the server to stay responsive while slow tasks continue in the background.

This entire approach is deeply connected to asynchronous programming in Node.js. Whether you are working with databases, APIs, file systems, timers, or sockets, you’ll constantly encounter non-blocking behavior everywhere. Once this concept becomes clear, understanding callbacks, promises, async-await, and the event loop becomes much easier because all of them are built around the same core idea of avoiding unnecessary waiting during execution.

Hope it helps!.

This is exactly where the event loop comes into the picture.
In this blog, we’ll understand what the event loop actually is, why Node.js needs it, how async operations work internally at a high level, and how all of this helps Node.js stay scalable. By the end, the whole “single-threaded but still asynchronous” thing will make much more sense.

Why Node.js Needed Something Like the Event Loop

Before understanding the event loop, we first need to understand the problem. JavaScript itself runs on a single thread. That simply means one thing executes at a time. Suppose JavaScript starts executing one function. Until that function finishes, the next function has to wait. This happens because JavaScript uses something called a call stack. Everything that executes in JavaScript first enters this stack, gets processed, and only then the next thing gets the chance to execute.
This works completely fine for small and fast operations, but the problem starts appearing when one operation becomes slow and blocks everything else behind it. like a very simple example:

function task1() {
  console.log("Task 1");
}

function task2() {
  console.log("Task 2");
}

task1();
task2();

It's output:

Task 1
Task 2

Everything looks fine here because both operations are quick. But now imagine one operation takes 5 seconds. During those 5 seconds, JavaScript cannot move ahead because the current task is still occupying the call stack.
That means every other operation behind it remains stuck until the current task completely finishes execution. This is where blocking behavior starts becoming a serious issue, especially in backend applications where multiple users may be sending requests together at the same time.

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

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

  console.log("Slow task completed");
}

function anotherTask() {
  console.log("Another task");
}

slowTask();
anotherTask();

Output after 5 seconds:

Slow task completed
Another task

Notice something important here. The second function had to wait completely. JavaScript could not move ahead until the first task finished. Now imagine this situation on a backend server. Suppose one user requests some large file from the database and the server blocks for a few seconds. If the entire server waits during that time, then every other incoming user also gets stuck. That would be terrible for scalability.

This is why Node.js needed a better mechanism to handle slow operations like database queries, API calls, file handling, timers, and network requests without blocking the entire execution flow.

So What Exactly is the Event Loop?

At a very high level, the event loop is simply a manager. Its job is to continuously check whether the call stack is empty and whether there are any completed async tasks waiting for execution. If the stack becomes empty and some async callback is ready, the event loop pushes that callback into the call stack so JavaScript can execute it. That’s the core idea behind the entire flow.
Node.js itself does not magically execute everything simultaneously inside JavaScript. Instead, it smartly delegates slow operations outside the main thread and keeps checking when those operations are completed so their callbacks can be executed later without blocking everything else.

Understanding the Flow Step by Step

Let’s take a small example first.

console.log("Start");

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

console.log("End");

It's output:

Start
End
Timer completed

At first this feels weird because many people expect the timer callback to execute before “End”. But the reason this does not happen is because the timer operation is asynchronous. When the code starts executing, “Start” goes into the call stack and executes immediately. Then setTimeout gets registered and Node.js hands over the timer responsibility to the underlying system APIs.
JavaScript does not stop and wait there. It immediately moves ahead and executes “End”. Once the timer duration completes after 2 seconds, the callback becomes ready. The event loop keeps checking whether the call stack is empty, and once it becomes empty, the callback is pushed into the stack and finally executes. This is the reason Node.js feels non-blocking even though JavaScript itself is single-threaded.

Call Stack vs Task Queue

To understand the event loop properly, these two concepts are important. The call stack is where functions execute, whereas the task queue stores completed async callbacks that are waiting for execution. Whenever an async operation completes, its callback does not directly jump into execution immediately. Instead, it first waits inside the queue.
The event loop continuously checks whether the call stack has become empty or not. If the stack is empty, then the callback is moved from the queue into the stack for execution. This entire cycle keeps repeating continuously while the application runs. At a conceptual level, this is the main relationship between the call stack, task queue, and the event loop.

Async Operations are Not Executed by JavaScript Alone

One common misconception is that JavaScript itself handles timers, file system operations, or network requests. It actually doesn’t. Things like setTimeout, file system operations, and HTTP requests are handled by Node.js APIs and system-level components running in the background. JavaScript only registers the callback function and continues moving ahead with the remaining code execution. Once the operation completes in the background, the callback is sent back and the event loop schedules it for execution whenever the call stack becomes free. This is why async operations do not block the main execution flow. For example:

const fs = require("fs");

console.log("Reading file...");

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

console.log("Other work continues...");

It's output:

Reading file...
Other work continues...
File content here

Notice again that JavaScript did not stop and wait for the file to be read completely. While the file system operation was happening in the background, JavaScript continued executing the remaining code normally. Once the file reading operation completed, its callback was brought back for execution. This is one of the biggest reasons Node.js performs well for backend applications where multiple I/O operations happen continuously.

Timers vs I/O Callbacks

At a high level, different async operations get handled differently internally. Timers like setTimeout wait for time completion, whereas I/O callbacks wait for operations like file reading, database queries, or network requests to finish. Internally, Node.js has different mechanisms to manage these operations efficiently, but from a beginner perspective, the important thing to understand is that both eventually place their callbacks into queues and the event loop decides when those callbacks should execute. You do not need to go very deep into internal phases initially because understanding the overall flow is far more important in the beginning.

Why the Event Loop Makes Node.js Scalable

This is probably the most important part of the entire discussion. Traditional blocking systems can waste a lot of time waiting for operations like database responses, file reads, or API results. During this waiting period, the server may become blocked and unable to efficiently process other incoming requests. Node.js avoids this issue completely by using asynchronous behavior along with the event loop. Instead of sitting idle and waiting for one operation to finish, Node.js keeps accepting and processing other requests while the slow operations continue in the background.

This leads to much better resource utilization and allows Node.js applications to handle a very large number of concurrent users efficiently. This is exactly why Node.js became extremely popular for APIs, real-time applications, chat systems, streaming platforms, and notification systems where continuous I/O operations are happening all the time. The event loop plays a huge role in making all of this possible because it allows JavaScript to stay non-blocking without creating unnecessary waiting situations.

Final Thoughts

The event loop is one of the most important concepts in Node.js because it explains how Node.js achieves asynchronous and non-blocking behavior even while JavaScript itself is single-threaded. Initially, the internals can feel confusing, especially when terms like queues, stacks, callbacks, and async operations start appearing together. But at its core, the idea is actually simple. JavaScript executes one thing at a time, slow operations get delegated outside the main thread, completed callbacks wait in queues, and the event loop keeps moving ready callbacks back into execution whenever the call stack becomes free.

Once this flow becomes clear, understanding async programming in Node.js becomes much easier because almost everything in backend development eventually connects back to this concept in one way or another. Whether you are working with APIs, databases, timers, sockets, or file handling, the event loop is constantly working in the background and making asynchronous execution possible.

I hope it helps.

What Are Cookies?

Cookies are small pieces of data stored inside the browser. Whenever a client sends a request to the server, the browser can automatically attach cookies along with that request. A cookie itself is not authentication. It is just a storage mechanism. For example, after login, the server may store something like this in the browser, and from there the browser keeps sending it automatically with future requests.
The important thing to understand is that cookies are simply used to store some data on the client side, and that data could be a session ID, a JWT token, user preferences, language settings, theme settings, or anything else.

document.cookie = "userId=12345";

Now every request can automatically carry this cookie.

Cookie: userId=12345

So cookies are storage. Not authentication logic itself. This is where many beginners get confused because they think cookies and sessions are the same thing, whereas cookies are just one way of storing or transporting some information between client and server.

What Are Sessions?

Sessions are a server-side authentication mechanism. When a user logs in successfully, the server creates a session for that user and stores session-related data somewhere on the server. That data may contain details like userId, sessionId, login state, expiry information, etc. Now the server needs some way to identify which session belongs to which user, and for that it usually sends the session ID back to the browser inside a cookie.
From the next request onwards, the browser automatically sends that cookie and the server checks whether that session exists and is valid.

{
  sessionId: "abc123",
  userId: 45,
  isLoggedIn: true
}

The server may send the session ID like this:

Set-Cookie: sessionId=abc123

And from the next request onwards:

Cookie: sessionId=abc123

Then the server checks whether this session ID exists, which user it belongs to, and whether the session is still valid or expired. If everything is valid, the request gets authenticated. So in session-based authentication, the session data lives on the server, while the session ID usually lives inside cookies. This is why sessions are called stateful authentication because the server is maintaining state for logged-in users.

Simple Session Flow

The flow usually starts when the user logs in and the server creates a session for that user. The server stores the session in memory or a database and then sends a session ID to the browser. The browser stores that session ID inside a cookie and automatically sends it in future requests.
Whenever the server receives a request, it checks whether the session ID is valid and maps it back to the stored session data. If the session exists and is active, the user gets authenticated. That is basically the complete idea behind session authentication and once you understand this flow, sessions become very easy to understand.

What Is JWT?

JWT stands for JSON Web Token. Unlike sessions, JWT authentication does not require the server to store authentication state separately for every user. Instead, the token itself carries the required information. After login, the server generates a JWT token and sends it to the client. The client then stores that token somewhere, usually inside localStorage, sessionStorage, or sometimes cookies. For every protected request, the token is sent back to the server and the server verifies its signature before authenticating the user.

A JWT payload may look something like this:

{
  userId: 45,
  role: "admin"
}

The server may generate it like this:

const token = generateJWT({
  userId: 45
});

And future requests may send it like this:

Authorization: Bearer jwt_token_here

The important difference here is that the server is not storing authentication state for every user separately like sessions do. The token itself contains the information required for authentication. This is why JWT authentication is called stateless authentication because the server does not need to remember users separately between requests.

Stateful vs Stateless Authentication

This is one of the most important concepts to understand while learning authentication because most confusion around sessions and JWT comes from here itself. In stateful authentication, the server stores authentication-related data and remembers users between requests. Sessions are the most common example of this approach. The server keeps track of logged-in users and validates requests based on data stored on the server side itself.

In stateless authentication, the server does not store login state separately for every user. Instead, every request contains everything required for authentication. JWT is the most common example here. The server only verifies the token and does not need to remember users separately in memory or database for authentication purposes. Once this difference becomes clear, understanding authentication flows becomes much easier.

Sessions vs JWT

This is where most confusion usually happens because people constantly ask which one is better. But honestly, both are useful depending on the type of project you are building and the kind of architecture you are working with. Sessions are often simpler to manage for traditional applications, whereas JWT becomes useful when frontend and backend are separated or multiple services need authentication handling.

The main thing to understand is not which one is universally better, but rather which one fits your project requirements properly. In real-world applications, both are still heavily used depending on scalability requirements, infrastructure, frontend architecture, and security handling preferences.

Session Authentication Flow

In session-based authentication, the client first sends a login request to the server. The server then creates a session and stores it internally. After that, the server sends a session ID back to the browser, usually through cookies. The browser stores that cookie and automatically attaches it with future requests. Whenever a request reaches the server, the server validates the session ID and maps it to the stored session data before authenticating the request.

Client → Login Request → Server
Server → Creates Session
Server → Sends Session ID Cookie
Browser → Stores Cookie
Browser → Sends Cookie On Every Request
Server → Validates Session

The actual authentication state exists on the server itself, which is why this approach is called stateful authentication.

JWT Authentication Flow

In JWT authentication, the client first sends login credentials to the server. The server validates them and generates a JWT token instead of creating a session. That token is sent back to the client and stored on the client side. For future requests, the client manually sends the token, generally through the Authorization header. The server then verifies the token signature and authenticates the request if the token is valid.

Client → Login Request → Server
Server → Generates JWT
Server → Sends JWT
Client → Stores Token
Client → Sends Token In Authorization Header
Server → Verifies JWT Signature

Here the token itself carries authentication information, which removes the need for maintaining server-side authentication state separately.

Where Cookies Fit In JWT?

This part confuses many people because tutorials often compare cookies and JWT as if they are direct competitors. Cookies and JWT are not competitors at all. JWT can also be stored inside cookies. That means sessions often use cookies, and JWT can also use cookies depending on implementation preferences. Cookies are simply storage or transport mechanisms. The real comparison is session-based authentication versus token-based authentication using JWT. Once this distinction becomes clear, a lot of confusion disappears automatically.

When Should You Use Sessions?

Sessions are still very commonly used in production systems. They work especially well when you have traditional server-rendered applications and want simpler authentication handling. They also make logout handling easier because invalidating a session on the server side is straightforward. Sessions are useful when you want stronger control over active users and when your application does not require highly distributed stateless scaling architecture. Frameworks like Express sessions, Django sessions, and Laravel sessions heavily use session-based authentication even today because for many projects, sessions are still completely fine and practical.

When Should You Use JWT?

JWT becomes useful when you are building APIs, mobile applications, or systems where frontend and backend are separated. It is also useful when multiple services need authentication verification without relying on centralized session storage. JWT fits very naturally into MERN stack applications because frontend and backend usually operate independently. Stateless authentication also makes horizontal scaling easier since servers do not need to maintain separate session storage for every logged-in user.

One Important Misconception

A lot of tutorials on the internet make JWT sound automatically superior to sessions, but that is not really true. JWT solves specific problems, and sessions solve specific problems. If your application does not actually require stateless authentication, sessions may even end up being simpler and easier to manage properly. In many real-world systems, companies even use hybrid approaches depending on different requirements inside different services. So instead of trying to find one universally better solution, it is much better to understand the strengths and tradeoffs of both approaches properly.

Final Thoughts

Understanding authentication becomes much easier once you stop mixing sessions, cookies, and JWT together. Cookies are simply storage mechanisms. Sessions are server-side stateful authentication. JWT is token-based stateless authentication. Both sessions and JWT are widely used in production systems and both solve valid real-world problems depending on project architecture and scalability requirements.

The important thing is not memorizing definitions. The important thing is understanding where authentication state lives and how the server verifies the user on every request. Once that clicks properly, the whole authentication flow starts making much more sense and choosing between sessions and JWT also becomes much easier.

Hope this helps, this is a bit longer than what I write generally but it was important to explain things in very easy manner and in detail instead of using jargons and by-passing things.

The Problem With Direct DOM Manipulation

Before understanding Virtual DOM, first we need to understand why React even needed it. Updating the Real DOM directly is expensive. By expensive, I do not mean money. I mean performance-wise.

The browser has to do a lot of work whenever the DOM changes. Things like:

• Recalculating layout

• Repainting elements

• Re-rendering parts of the UI

• Reflowing the page structure

And if updates happen very frequently, direct DOM manipulation can become slow very quickly. Imagine having a huge UI with hundreds of elements and changing things manually every time state changes.

const heading = document.getElementById("title");

heading.innerText = "New Title";

This looks harmless. But when applications become large and updates happen continuously, manually updating the DOM becomes difficult to manage and expensive for the browser. This is the exact problem React tries to solve.

Real DOM vs Virtual DOM

The Real DOM is the actual DOM that exists inside the browser. It is what the browser uses to display your webpage visually. Whenever something changes in the UI, the browser updates the Real DOM.
The Virtual DOM, on the other hand, is just a lightweight JavaScript representation of the Real DOM. It is not an actual browser DOM. It is basically a JavaScript object tree that React creates and manages internally.
A very simplified example looks something like this:

const virtualDOM = {
  type: "h1",
  props: {
    children: "Hello"
  }
};

React uses these lightweight objects because comparing JavaScript objects is much faster than directly touching the Real DOM repeatedly. So instead of updating the Real DOM immediately every time something changes, React first works with this Virtual DOM representation.

What Happens During Initial Render

Now let’s understand the actual flow. When a React application renders for the very first time, React creates a Virtual DOM tree for the entire component structure.

Suppose we have this component:

function App() {
  return (
    <div>
      <h1>Hello</h1>
      <p>Welcome</p>
    </div>
  );
}

React converts this into a Virtual DOM tree internally. Something conceptually like this:

{
  type: "div",
  children: [
    {
      type: "h1",
      children: ["Hello"]
    },
    {
      type: "p",
      children: ["Welcome"]
    }
  ]
}

After creating this Virtual DOM tree, React uses it to build the actual Real DOM elements inside the browser. So the flow becomes:
Component → Virtual DOM → Real DOM
At this point, the UI becomes visible on the screen.

What Happens When State or Props Change

Now comes the important part. Suppose we have a component like this:

import { useState } from "react";

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

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

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

Initially, count is 0. React creates a Virtual DOM tree for it and renders the UI.

Now when the button is clicked:

setCount(count + 1);

React understands that state has changed. And this triggers a re-render.

A lot of beginners think React directly updates the browser DOM here. That is not what happens. Instead, React creates an entirely new Virtual DOM tree again.

This new tree represents what the UI should look like after the state update. So now React has:

• Old Virtual DOM tree

• New Virtual DOM tree

And now comes the core concept.

What is Diffing in React

Diffing simply means comparing the old Virtual DOM tree with the new Virtual DOM tree. React checks: “What actually changed?” This entire comparison process is called reconciliation.
The goal is simple: Find the minimum number of changes needed to update the UI.For example : - Before update:

<h1>0</h1>

After update:

<h1>1</h1>

React compares both trees and notices: Only the text inside h1 changed.
The div did not change. The button did not change. Everything else stayed the same.
So React updates only that specific part. This is the biggest advantage. Instead of rebuilding the entire UI, React updates only the changed nodes.

How React Applies Minimal Changes

Once React finishes comparing the trees, it creates something called an update patch internally. This patch contains only the necessary changes.
Then React updates the Real DOM with only those specific modifications. So instead of doing something like: “Destroy everything and rebuild the entire page” React does: “Only update the exact thing that changed”
That is why React applications feel fast and efficient. Especially in large applications where updates happen continuously.

Why Virtual DOM Improves Performance

A common misconception is that Virtual DOM itself is magically fast. That is not entirely true.

The actual benefit comes from minimizing expensive Real DOM operations. React avoids unnecessary DOM updates by:

• Comparing old and new Virtual DOM trees

• Detecting only changed parts

• Updating only those nodes in the Real DOM

Since DOM manipulation is expensive but JavaScript object comparison is relatively cheap, this approach improves performance significantly. Especially for dynamic UIs.

The Overall React Update Flow

At a high level, React’s update lifecycle looks like this:
State/Props Change → New Virtual DOM Created → Diffing Happens → Minimal Changes Identified → Real DOM Updated
This entire cycle happens very quickly behind the scenes. Most of the time, we do not even notice it happening.
And honestly, this is one of the reasons React became so popular. Developers can focus on describing the UI instead of manually updating DOM elements every time something changes.

One Important Thing to Understand

A re-render does not mean the entire Real DOM gets rebuilt. This is one of the most misunderstood things among beginners.
Re-rendering mainly means: React creates a new Virtual DOM tree again.
After that, React compares it with the previous one and updates only the necessary parts in the Real DOM. So even if a component re-renders, React still tries to minimize actual browser DOM changes.
That is the entire idea behind reconciliation.

Final Thoughts

Virtual DOM is not some magical browser feature. It is simply a smart strategy React uses to make UI updates efficient.
The important thing is not memorizing definitions like: “Virtual DOM is a lightweight copy of the Real DOM.”
The real understanding comes from knowing the flow:

• React creates Virtual DOM

• State changes trigger re-render

• New Virtual DOM gets created

• React compares old vs new trees

• Only necessary updates are applied to the Real DOM

Once this mental model becomes clear, a lot of React concepts start making much more sense automatically.

I hope this simple explanation in easy language would have made the virtual DOM concept and how React works, clear to you.

What spread operator does

Spread operator is used to take values from an iterable like an array or object and expand them into individual elements. It basically opens up the structure and places the values where needed.

const numbers = [10, 20, 30];

const newNumbers = [...numbers];

console.log(newNumbers);

// Output:
// [10, 20, 30]

Here, the values from numbers are expanded into newNumbers. It is not referencing the same array, it creates a new one with copied values.

Spread is very useful when we want to copy or combine arrays.

const arr1 = [1, 2];
const arr2 = [3, 4];

const combined = [...arr1, ...arr2];

console.log(combined);

// Output:
// [1, 2, 3, 4]

Here both arrays are expanded and merged into one.

Using spread with objects

Spread also works with objects. It helps in copying properties or merging objects.

const user = {
  name: "Gaurang",
  age: 21
};

const updatedUser = {
  ...user,
  role: "Developer"
};

console.log(updatedUser);

// Output:
// { name: "Gaurang", age: 21, role: "Developer" }

Here all properties from user are expanded into updatedUser, and then a new property is added.

What rest operator does

Rest operator does the opposite of spread. Instead of expanding values, it collects multiple values into a single variable. It is commonly used in function parameters or destructuring.

function sum(...numbers) {
  console.log(numbers);
}

sum(10, 20, 30);

// Output:
// [10, 20, 30]

Here, all arguments are collected into the numbers array.
Rest can also be used in array destructuring.

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

const [first, ...rest] = numbers;

console.log(first);
console.log(rest);

// Output:
// 10
// [20, 30, 40]

Here first gets 10, and the remaining values are collected into rest.

Differences between spread and rest

Even though both use the same three dots syntax, their behavior is different based on usage. Spread is used when we want to expand values, rest is used when we want to collect values.
Spread is usually seen on the right side when assigning or passing values, while rest is usually seen on the left side when receiving values.

Practical use cases

Spread is commonly used when copying arrays or objects, merging multiple arrays, or passing elements as individual arguments to functions.

const numbers = [1, 2, 3];

function add(a, b, c) {
  console.log(a + b + c);
}

add(...numbers);

// Output:
// 6

Here spread expands the array into individual arguments.
Rest is useful when we do not know how many arguments will be passed and we want to handle them as a group.

function logAll(...values) {
  console.log(values);
}

logAll("a", "b", "c");

// Output:
// ["a", "b", "c"]

It collects all arguments into a single array.

Final clarity

Spread and rest use the same syntax but solve opposite problems. Spread expands values from arrays or objects, while rest collects multiple values into one variable. Once you focus on whether values are being expanded or collected, it becomes easy to understand where to use each of them.

What Map is

Map is a collection of key value pairs, similar to objects, but with more flexibility. In Map, keys can be of any type, not just strings. That means you can use numbers, objects, or even functions as keys.

const map = new Map();

map.set("name", "Gaurang");
map.set(1, "One");

console.log(map.get("name"));
console.log(map.get(1));

Here we are storing values using different types of keys. This is something that objects do not support directly.
Another important thing is that Map maintains insertion order, so the order in which you add entries is preserved.

What Set is

Set is a collection of unique values. It automatically removes duplicates, which is something arrays do not do.

const set = new Set();

set.add(10);
set.add(20);
set.add(10);

console.log(set);

Even though we added 10 twice, it will only be stored once. That is because Set only keeps unique values.
This makes Set very useful when you want to remove duplicates from a list or ensure that only unique values are stored.

Problem with traditional objects

Objects are useful, but they have limitations. Keys are always treated as strings, even if you use numbers. Also, objects are not designed for frequent additions and deletions in the same way Map is.

const obj = {};

obj[1] = "One";
obj["1"] = "Duplicate";

console.log(obj);

Here both keys will be treated the same, because object keys are converted to strings.

Map vs Object

Map provides better flexibility compared to objects when it comes to key value storage. Keys in Map can be of any type, whereas in objects they are limited. Map also has built in methods like set, get, has, and delete which make operations more structured.

const map = new Map();

map.set({ id: 1 }, "User1");
map.set({ id: 2 }, "User2");

console.log(map.size);

This kind of usage is not possible with objects in a reliable way because objects do not handle non string keys properly.

Problem with arrays

Arrays allow duplicate values, which is not always desired. If you are storing data where uniqueness matters, arrays require extra logic to handle duplicates.

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

console.log(numbers);

Here duplicates are allowed, and you would need to manually filter them out if required.

Set vs Array

Set solves this problem by ensuring uniqueness automatically. It stores only unique values and ignores duplicates.

const numbers = new Set([10, 20, 10, 30]);

console.log(numbers);

Now you do not need extra logic to remove duplicates. Set handles it internally.

When to use Map and Set

Map is useful when you need flexible key value storage and when keys are not just strings. It is also helpful when you need to maintain insertion order and perform frequent operations like add, delete, and lookup.
Set is useful when you want to store unique values and avoid duplicates without writing extra logic. It is commonly used when working with lists where repetition is not allowed.

Final clarity

Map and Set are alternatives to objects and arrays for specific use cases. Map improves key value handling by allowing any type of keys and providing better control over operations. Set ensures uniqueness and simplifies working with collections of values where duplicates are not needed.
So instead of forcing everything into objects and arrays, using Map and Set where they fit makes the code cleaner and more efficient.

What destructuring means ?

Normally, when we access values from an object or array, we do it step by step. Destructuring allows us to do that in a shorter and more readable way by matching structure on the left side.

Let’s first see how things are done without destructuring.

const user = {
  name: "Gaurang",
  age: 21,
  role: "Developer"
};

const name = user.name;
const age = user.age;
const role = user.role;

console.log(name, age, role);

Now the same thing using destructuring:

const user = {
  name: "Gaurang",
  age: 21,
  role: "Developer"
};

const { name, age, role } = user;

console.log(name, age, role);

Here, instead of writing multiple lines, we extracted everything in one go.

Destructuring arrays

Destructuring also works with arrays. In arrays, the position matters instead of the property name.

const numbers = [10, 20, 30];

const first = numbers[0];
const second = numbers[1];
const third = numbers[2];

console.log(first, second, third);

Now using destructuring:

const numbers = [10, 20, 30];

const [first, second, third] = numbers;

console.log(first, second, third);

Here, the first variable gets the first value, second gets the second, and so on. It directly maps based on index.

Destructuring objects

In objects, destructuring works based on property names, not position.

const player = {
  name: "Virat",
  role: "Batter",
  team: "India"
};

const { name, role } = player;

console.log(name, role);

Here, variables name and role are created and assigned from the object. If the property names match, destructuring becomes very straightforward.

Default values

There are cases where some values might not exist. In those situations, destructuring allows us to assign default values.

const user = {
  name: "Gaurang"
};

const { name, age = 20 } = user;

console.log(name, age);

Here, age does not exist in the object, so it takes the default value 20. This helps avoid undefined values and makes code safer.

Before vs after destructuring

Without destructuring, extracting multiple values leads to repetitive code. With destructuring, the same work becomes shorter and more readable.

const product = {
  title: "Laptop",
  price: 50000,
  brand: "HP"
};

const title = product.title;
const price = product.price;
const brand = product.brand;

console.log(title, price, brand);

const product = {
  title: "Laptop",
  price: 50000,
  brand: "HP"
};

const { title, price, brand } = product;

console.log(title, price, brand);

The second version is cleaner and reduces repetition.

Benefits of destructuring

Destructuring helps in writing less code, improves readability, and makes it easier to work with objects and arrays. It is especially useful when dealing with function parameters, API responses, or any structured data.
It also makes the intent clearer, since we can directly see what values are being extracted instead of scanning multiple lines.

Final clarity

Destructuring is just a cleaner way to extract values from arrays and objects. Arrays use position based extraction, objects use property names, and default values help handle missing data. It does not introduce new behavior, it just simplifies existing patterns and makes code easier to read and maintain.

Let’s start with a very basic runtime error so that the problem becomes clear.

console.log("Start");

let user = undefined;
console.log(user.name);

console.log("End");

Here, the moment JavaScript tries to access user.name, it throws an error because user is undefined. Because of this, the program stops immediately and "End" never gets printed. This is what happens when errors are not handled, execution breaks in between.

What errors are in JavaScript

Errors are situations where the code cannot execute as expected. These are usually runtime issues, meaning they occur when the code is running, not when it is written. JavaScript throws these errors automatically when it encounters something invalid, like accessing properties on undefined, calling something that is not a function, or invalid operations.
If we do not handle these errors, they bubble up and stop execution, which is not ideal in most real applications.

Using try and catch blocks

To handle such situations, JavaScript provides try and catch. The idea is simple, we try to execute a block of code, and if any error occurs inside it, we catch it and handle it.

console.log("Start");

try {
  let user = undefined;
  console.log(user.name);
} catch (error) {
  console.log("Something went wrong");
}

console.log("End");

Now instead of breaking the program, the error is caught, and the program continues executing. So "End" will be printed.
This is called graceful failure. Instead of crashing, we handle the issue and move forward.

The finally block

There are situations where we want some code to run no matter what, whether an error occurs or not. That is where finally comes in.

try {
  console.log("Inside try");
} catch (error) {
  console.log("Inside catch");
} finally {
  console.log("This always runs");
}

The finally block always executes. Even if there is no error, or even if there is an error and it is caught, finally will still run. This is useful for cleanup tasks or closing resources.

Throwing custom errors

JavaScript also allows us to create our own errors using throw. This is useful when we want to enforce certain conditions manually.

function withdraw(amount) {
  if (amount > 1000) {
    throw new Error("Limit exceeded");
  }
  console.log("Withdrawal successful");
}

try {
  withdraw(2000);
} catch (error) {
  console.log(error.message);
}

Here, we are manually throwing an error when a condition is not met. This helps in controlling the flow and making sure invalid operations are not silently ignored.

Why error handling matters

Error handling is important because it prevents your application from crashing unexpectedly. It allows you to show proper messages, log issues for debugging, and keep the rest of the application running.
Without error handling, even a small issue can break the entire flow. With proper handling, you can isolate the problem and deal with it in a controlled way.
It also helps a lot during debugging. Instead of getting random crashes, you get clear points where things failed, which makes it easier to fix issues.

Final clarity

Errors are a natural part of programming, especially in JavaScript where many things happen at runtime. Try and catch help in handling these errors gracefully, finally ensures that certain code always runs, and throw allows us to create our own errors when needed.
So instead of letting your program break, you take control of how it behaves when something goes wrong, and that is the main idea behind error handling in JavaScript.

Starting with a file reading example

Let’s take a very simple example of reading a file. In Node.js, we usually use asynchronous file reading so that the program does not block.

const fs = require("fs");

console.log("Start");

fs.readFile("data.txt", "utf-8", (err, data) => {
  if (err) {
    console.log("Error reading file");
    return;
  }
  console.log("File content:", data);
});

console.log("End");

Here, even though the file is being read in between, the output will be:

**Start

**End

*File content: ...

This happens because file reading is asynchronous. Node.js starts the operation and moves ahead, and once the data is ready, the callback function is executed.

Callback based async execution

Callbacks are one of the earliest ways to handle asynchronous code in JavaScript. A callback is simply a function that is passed as an argument and is executed later when the async task is completed.
In the previous example, the function inside readFile is the callback. It runs only after the file has been read.
The flow is simple, start the task, continue execution, and once the task finishes, run the callback. This allows non blocking behavior.

Problem with nested callbacks

The problem starts when we have multiple async operations that depend on each other. Then callbacks start getting nested inside each other, which makes the code harder to read and maintain.

const fs = require("fs");

fs.readFile("file1.txt", "utf-8", (err, data1) => {
  if (err) return console.log(err);

  fs.readFile("file2.txt", "utf-8", (err, data2) => {
    if (err) return console.log(err);

    fs.readFile("file3.txt", "utf-8", (err, data3) => {
      if (err) return console.log(err);

      console.log(data1, data2, data3);
    });
  });
});

This structure keeps going deeper as more operations are added. It becomes difficult to follow the flow, handle errors properly, and debug issues. This is commonly referred to as callback nesting, and it quickly becomes messy.

Promise based async handling

To solve the readability issue of callbacks, promises were introduced. A promise represents a value that may be available now, later, or never. Instead of passing callbacks, we return promises and handle results using then and catch.

Let’s convert the file reading example into promise based code.

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

console.log("Start");

fs.readFile("data.txt", "utf-8")
  .then((data) => {
    console.log("File content:", data);
  })
  .catch((err) => {
    console.log("Error reading file");
  });

console.log("End");

The behavior is still asynchronous, but the structure is cleaner. Instead of nesting, we chain operations.

Handling multiple operations with promises

The earlier nested example can now be written in a much cleaner way.

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

fs.readFile("file1.txt", "utf-8")
  .then((data1) => {
    return fs.readFile("file2.txt", "utf-8").then((data2) => {
      return { data1, data2 };
    });
  })
  .then(({ data1, data2 }) => {
    return fs.readFile("file3.txt", "utf-8").then((data3) => {
      console.log(data1, data2, data3);
    });
  })
  .catch((err) => {
    console.log(err);
  });

Even though this is still not perfect, it is more readable compared to deeply nested callbacks.

Benefits of promises

Promises solve multiple issues that callbacks had. The code becomes flatter, easier to read, and error handling becomes more consistent because we can use a single catch block. It also becomes easier to chain operations and manage flow without going deep into nested structures.
Another advantage is that promises can be combined with async and await, which makes the code even more readable and closer to synchronous style, while still being asynchronous underneath.

Final clarity

Async code exists in Node.js to prevent blocking and to make efficient use of the single threaded nature of JavaScript. Callbacks were the initial way to handle async operations, but they become difficult to manage when multiple steps are involved. Promises improve this by providing a cleaner and more structured way to handle async flow.
So the progression becomes clear, callbacks handle async tasks but can get messy, promises improve readability and structure, and later async and await make it even simpler to write and understand.

Why async and await were introduced

When promises were introduced, they improved things compared to callbacks, but chaining then and catch multiple times can still make code look complex. As the number of async operations increases, readability becomes an issue and debugging also gets harder.

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

fetchData()
  .then((data) => {
    console.log(data);
    return "Next step";
  })
  .then((res) => {
    console.log(res);
  })
  .catch((err) => {
    console.log(err);
  });

This works fine, but as more steps get added, it becomes harder to follow the flow. That is where async and await improve things by making the code look more like synchronous code.

How async functions work

An async function is just a function that always returns a promise. Even if you return a normal value, it will be wrapped inside a promise automatically.

async function greet() {
  return "Hello";
}

greet().then((res) => console.log(res));

Here, even though we returned a string, it is treated as a resolved promise.
So the key idea is that async makes a function return a promise.

Await keyword concept

Await is used inside async functions to pause the execution until a promise is resolved. It makes the code look like it is running step by step, even though it is still asynchronous underneath.

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

async function getData() {
  console.log("Start");

  const data = await fetchData();
  console.log(data);

  console.log("End");
}

getData();

Here, await pauses the function at that line until fetchData resolves, and then continues execution. So the flow becomes much easier to read.

Comparison with promises

The same example using promises would look like this:

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

function getData() {
  console.log("Start");

  fetchData().then((data) => {
    console.log(data);
    console.log("End");
  });
}

getData();

Both approaches achieve the same result, but the async and await version looks more linear and easier to follow.

Error handling with async code

Error handling becomes cleaner with async and await because we can use try and catch instead of chaining catch methods.

function fetchData() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject("Something went wrong");
    }, 2000);
  });
}

async function getData() {
  try {
    const data = await fetchData();
    console.log(data);
  } catch (error) {
    console.log(error);
  }
}

getData();

This makes error handling look similar to synchronous code, which improves readability.

Final clarity

Async and await were introduced to make working with promises simpler and more readable. Async ensures that a function returns a promise, and await allows us to write asynchronous code in a step by step manner. Internally, everything is still based on promises, but the syntax makes it easier to understand and maintain.
So whenever you see async and await, think of them as a cleaner layer over promises that helps you write code that is easier to read and reason about.

What synchronous code means

Synchronous code means the code runs step by step in order. Each line waits for the previous one to finish before it starts executing. There is no skipping, no delay handling, just straight execution.

console.log("Start");

function task() {
  console.log("Task running");
}

task();

console.log("End");

Here the output will always be:

**Start

*Task running

**End

This is because each line completes before moving to the next one. This is called blocking behavior because if one line takes time, everything after it has to wait.

Blocking problem in synchronous code

Now the issue with synchronous code shows up when a task takes time. Suppose there is a heavy operation or something that takes a few seconds, everything after it gets blocked.

console.log("Start");

function heavyTask() {
  for (let i = 0; i < 1e9; i++) {}
  console.log("Heavy task done");
}

heavyTask();

console.log("End");

Here End will only print after the loop finishes. So the entire program is stuck until that work is done. This is what blocking looks like, nothing else can move forward.

What asynchronous code means

Asynchronous code allows certain tasks to run in the background without blocking the main execution. That means JavaScript can start something, move ahead, and then come back to it later when it is done.
So instead of waiting, it continues executing the next lines.

console.log("Start");

setTimeout(() => {
  console.log("Async task done");
}, 2000);

console.log("End");

The output will be:

**Start

**End

*Async task done

Even though the timeout was written in between, it runs later. This is non blocking behavior.

Why JavaScript needs asynchronous behavior

JavaScript runs on a single thread. That means it can do one thing at a time. If everything was synchronous, then any slow operation like fetching data from an API or reading a file would block the entire application.
Imagine clicking a button on a website and the UI freezes because it is waiting for data. That would be a bad experience. So JavaScript uses asynchronous behavior to handle these situations without stopping everything else.
This allows things like UI updates, user interactions, and other operations to continue smoothly.

Example with API like behavior

A very common real world case is fetching data. Even though we are not actually calling an API here, the behavior can be understood like this.

console.log("Start");

function fetchData() {
  setTimeout(() => {
    console.log("Data received");
  }, 2000);
}

fetchData();

console.log("End");

Again, the output will be:

**Start

**End

*Data received

So JavaScript did not wait for the data, it moved ahead and handled it later.

Blocking vs non blocking clarity

In synchronous code, each line blocks the next one until it finishes. In asynchronous code, certain operations are handed off and JavaScript continues executing other lines.
This is why asynchronous code is called non blocking, because it does not stop the flow of execution.

What is happening behind the scenes

When an asynchronous task like setTimeout is called, it is not executed immediately by the main thread. It is handled separately and once it is ready, it is pushed back to be executed.
That is why even if it appears in between, it runs after the main synchronous code finishes.

Final clarity

Synchronous code runs line by line and blocks execution until each step is complete. Asynchronous code allows certain tasks to run separately so that the main execution does not stop. This is important because JavaScript is single threaded and needs a way to handle slow operations without freezing everything.
So whenever you see something like timers, API calls, or delayed execution, that is JavaScript handling things asynchronously to keep the application responsive.

Once this clicks, most of the confusion around this goes away. So instead of trying to memorize cases, it is better to focus on one simple idea, who is calling the function, that is what this will point to.

What "this" represents

"this" represents the object that is calling the function. It is decided at runtime, not at the time of writing the code. That is why the same function can behave differently depending on how it is called.
So if a function is called by an object, this points to that object. If it is called directly, then this depends on the environment.

this in global context

In the global scope, this behaves differently depending on where the code is running. In browsers, if you are in non strict mode, this refers to the global object which is window. In Node, it is different, but for simplicity, think of it as the global object in that environment.

console.log(this);

If you run this in a browser, you will see the window object.

this inside objects

When a function is defined inside an object and called using that object, "this" points to that object. This is one of the most common use cases.

const user = {
  name: "Gaurang",
  greet: function () {
    console.log("Hi, I am " + this.name);
  }
};

user.greet();

Here greet is called using user, so "this" points to user. That is why this.name gives "Gaurang".

this inside functions

Now this is where confusion usually starts. When a function is called normally, not attached to any object, "this" does not point to any custom object.

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

show();

In non strict mode in browsers, "this" will point to window. In strict mode, it will be undefined. So again, there is no object calling this function, that is why "this" does not point to something meaningful here.

How calling context changes this

This is the most important part. The value of "this" changes based on how the function is called, not where it is defined.

const person = {
  name: "Virat",
  greet: function () {
    console.log(this.name);
  }
};

person.greet();

Here "this" points to person because person is calling greet.

Now if we take the same function and call it differently:

const person = {
  name: "Virat",
  greet: function () {
    console.log(this.name);
  }
};

const greetFunction = person.greet;
greetFunction();

Now the function is called without person, so "this" will not point to person anymore. In browser non strict mode, it will point to window, and since window.name is usually empty, it will not give "Virat".

This clearly shows that this depends on the calling context.

Another simple example

const player = {
  name: "Bumrah",
  role: "Bowler",
  introduce: function () {
    console.log(this.name + " is a " + this.role);
  }
};

player.introduce();

Here "this" refers to player, so the output is based on player’s data.

If the same function is used somewhere else without the object, the value of "this" changes.

Final clarity

The main idea is simple and everything revolves around it. "this" represents the caller of the function. It is not about where the function is written, it is about how the function is called. In object methods, "this" points to the object. In normal function calls, it depends on the environment. And if the calling context changes, the value of this also changes.

Once you start looking at this as caller based, the confusion reduces a lot and it becomes much easier to predict what this will be in any given situation.

When we use new before a function, JavaScript performs multiple steps behind the scenes in one go. It creates a new empty object, then it links this object to the prototype of the constructor function, after that it calls the constructor function and sets this to point to that new object, then it assigns properties to this, and finally it returns that object automatically. So the important idea here is not that a new prototype is created, but that the new object gets linked to an already existing prototype, and that is what enables sharing and inheritance.

Constructor functions

A constructor function is just a normal function, but the difference is that we use it with new to create objects. This pattern is widely used to create multiple objects with similar structure. Instead of manually creating objects again and again, we define a constructor once and reuse it.

function Cricketer(name, role) {
  this.name = name;
  this.role = role;

  this.introduce = function () {
    console.log("Hi, I am " + this.name + " and I am a " + this.role);
  };
}

const player1 = new Cricketer("Virat Kohli", "Batter");
const player2 = new Cricketer("Jasprit Bumrah", "Bowler");

Both player1 and player2 are separate objects created using the same constructor, they have similar structure but different values.

Object creation step by step

When we write something like creating a new object using a constructor, it might look simple from outside but internally multiple things are happening in sequence. JavaScript is not just calling a function, it is preparing a complete object setup before returning it.

const player = new Cricketer("Virat Kohli", "Batter");

Internally, JavaScript is doing something very close to this flow, which helps in understanding what exactly is happening under the hood.

const obj = {};
Object.setPrototypeOf(obj, Cricketer.prototype);
Cricketer.call(obj, "Virat Kohli", "Batter");
return obj;

So the overall flow becomes constructor to new object creation, then prototype linking, then property assignment using this, and finally returning that object. This entire process is automatically handled by the new keyword.

Prototype linking and inheritance

Every function in JavaScript has a prototype property, and when we use new, the created object gets linked to that prototype. This is where the concept of inheritance comes into picture, not by copying data, but by linking objects.

function Cricketer(name, role) {
  this.name = name;
  this.role = role;
}

Cricketer.prototype.introduce = function () {
  console.log("Hi, I am " + this.name + " and I am a " + this.role);
};

const player1 = new Cricketer("Virat Kohli", "Batter");
const player2 = new Cricketer("Bumrah", "Bowler");

Here, introduce is not created separately for each object, instead both objects access it through the prototype. This means memory is used efficiently and behavior is shared. Because of this linking, the new object can access properties and methods defined on the prototype, and that is how inheritance works in this case.

Relation between constructor and instance

The relation is quite straightforward once seen clearly. The constructor acts as a blueprint which defines what structure and behavior an object should have. The instance is the actual object that gets created using that blueprint. So in this case, Cricketer is the constructor, and player1 and player2 are instances. Each instance has its own data like name and role, but they can share methods through the prototype.

How this behaves

When we use new, this refers to the newly created object every single time. That is why even if the same constructor and same methods are used, the output can be different because the data inside each object is different.

const player1 = new Cricketer("Virat Kohli", "Batter");
const player2 = new Cricketer("Bumrah", "Bowler");

player1.introduce();
player2.introduce();

Even though both are using the same introduce method, this points to player1 in the first call and player2 in the second call. So the values of name and role change accordingly, which results in different outputs.

Constructor vs factory function

There is another way of creating objects which is factory functions, and it is useful to understand the difference between both approaches because both are used in real codebases.

function User(name) {
  this.name = name;
}

const u1 = new User("A");

function createUser(name) {
  return {
    name: name
  };
}

const u2 = createUser("A");

In constructor functions, the new keyword handles object creation and binding of this automatically, whereas in factory functions we manually create and return the object. Both achieve similar outcomes but the internal approach is different.

Classes are just a wrapper over this

You must have come across classes in JavaScript, and they might look like something very different at first, but internally they are just a cleaner syntax over constructor functions and prototype logic. They do not introduce a new system, they just make the same thing easier to write and read.

class Cricketer {
  constructor(name, role) {
    this.name = name;
    this.role = role;
  }

  introduce() {
    console.log("Hi, I am " + this.name + " and I am a " + this.role);
  }
}

const player1 = new Cricketer("Virat Kohli", "Batter");

Internally, this still uses prototypes. Also, type of class is function, which shows that classes are just syntactic sugar over the existing system.

Instances created from constructors

When we use constructor functions with new, a new instance of the object is created every time. Each instance is independent in terms of data but can share behavior through the prototype.

const player1 = new Cricketer("Virat Kohli", "Batter");
const player2 = new Cricketer("Bumrah", "Bowler");

Both of these are different instances, and even though they are created from the same constructor, they do not interfere with each other’s data.

player1.introduce();
player2.introduce();

This is why calling methods on each instance produces different outputs, because this refers to the respective object each time.

Final clarity

The main idea is that the new keyword creates a new object, links that object to the constructor’s prototype, sets this to that object, and then returns it. Because of prototype linking, the object can access shared methods and properties, which is how inheritance is achieved here. At the same time, each instance remains independent in terms of its own data, which is why this behaves differently for each object created using the same constructor.