DEV Community: Ramanand Thakur

🚀 Express.js Fundamentals – Understanding Request/Response Lifecycle and Middleware

Ramanand Thakur — Thu, 25 Jun 2026 15:38:35 +0000

Express isn't just a framework that makes routing easier. Its real power comes from the Request/Response Lifecycle and Middleware architecture. By learning these two concepts you'll understand most of Express internals and be able to confidently debug real-world applications.

So far, we've seen that raw Node.js is powerful.

But after writing a few routes, things get messy quickly.

const http = require("http");
const server = http.createServer((req, res) => {
  if (req.url === "/users") {
    res.end("Users");
  } else if (req.url === "/products") {
    res.end("Products");
  } else {
    res.end("404");
  }
});

Imagine maintaining this with:

100 routes
Authentication
Validation
Logging
Error handling

That's a nightmare.

Express solves this by introducing:

Clean routing
Middleware
Request parsing
Error handling
Extensibility

In this article, we'll build a mental model of how Express works internally.

🎯 What You'll Learn

By the end of this guide you'll understand:

✅ Scaffolding

✅ Request lifecycle

✅ Request object

✅ Response object

✅ Middleware architecture

✅ Middleware execution order

✅ Error handling

📌 Prerequisites

You should be comfortable with:

Basic JavaScript
Node.js fundamentals
npm
HTTP basics

If you've completed the previous Node.js article, you're ready.

🏗️ What is Scaffolding?

When we hear the word scaffolding, it often sounds complicated.
In reality, it's a construction term.
When a building is being built, workers first create temporary support structures called scaffolds.
Only then do they start building floors, walls, and rooms.
The same idea applies to software development.

Scaffolding is the process of creating the initial structure of an application before writing actual business logic.
Think of it as preparing the foundation of your project.
Before building APIs, authentication, databases, and features, we first decide:

Where routes will live
Where middleware will live
Where controllers will live
Where configuration files will live
How the project will be organized

Without scaffolding, projects quickly become difficult to maintain.

Imagine building a house.
You don't start by placing random bricks.
You first create a blueprint.

House
│
├── Living Room
├── Kitchen
├── Bedroom
└── Bathroom

Because each room has a specific purpose.
Similarly, in an Express application:

Application
│
├── Routes
├── Controllers
├── Middleware
├── Models
└── Config

Each folder has a specific responsibility.
This organization makes the project easier to understand and maintain.

🌐 Understanding the Request/Response Lifecycle

🛫 Think of It Like Airport Security

When you board a flight:

A web request works similarly:

📊 Lifecycle Overview

🔥 What Happens Internally?

Suppose the browser sends:

GET /users/42?page=1 HTTP/1.1

Express processes the request in stages.

Stage 1: Express Creates req and res

Express generates:

req

and

res

objects.

These travel together through the entire lifecycle.

Think of them as a package moving through a conveyor belt.

Stage 2: Middleware Executes

Every registered middleware runs.

app.use(logger);

app.use(auth);

Execution order:

logger
↓
auth
↓
route handler

Order matters.

Always.

Stage 3: Route Matching

Express searches for matching routes.

app.get("/users/:id");

Request:

/users/42

Match found ✅

Handler executes.

Stage 4: Business Logic Runs

Database queries.

Validation.

Authorization.

Processing.

Everything happens here.

Stage 5: Response Sent

res.json(...)

res.send(...)

Browser receives response.

Lifecycle ends.

Now we know the lifecycle of a request - but let's zoom out. Your API receives an HTTP Request with multiple compartments. Let's understand which compartment holds which data, and how Express extracts it.

What is an HTTP Request?

At its core, an HTTP request is just a plain text string sent over a TCP socket from a client (browser, mobile app, cURL) to a server.

That string follows a strict format defined by the HTTP protocol. It looks like this:

POST /api/users?role=admin HTTP/1.1
Host: mywebsite.com
Authorization: Bearer xyz123
Content-Type: application/json
Content-Length: 27

{ "name": "Rama", "age": 25 }

This text is broken down into 4 distinct parts by your web framework (Express, Fastify, etc.). They are:

The Request Line (Method + Path + Query + Protocol)
The Headers (Metadata)
The Body (Data payload)
The Route Parameters (Dynamic segments in the URL path)

Express takes this raw string, parses it into a JavaScript object (req), and gives it to you. Let's decode every piece.

HTTP Request Types (The Methods)

When we say "request types", we mean HTTP Methods (or Verbs). These define the intent of the request.

Method	Intent	Is it Idempotent?*	Has a Body?
GET	Fetch data.	Yes	No (Never)
POST	Create a new resource.	No	Yes
PUT	Replace an entire resource entirely.	Yes	Yes
PATCH	Partially update a resource.	No	Yes
DELETE	Remove a resource.	Yes	No (Usually)
OPTIONS	Ask the server what methods are allowed (CORS preflight).	Yes	No
HEAD	Same as GET, but only returns headers, not the body.	Yes	No

*Idempotent means making the exact same request 1 time or 100 times produces the exact same result on the server (no side effects). If you PUT the same data 10 times, the final state is identical.

Crucial Rule: You access these in Express via req.method.

app.use((req, res, next) => {
  if (req.method === 'GET') console.log('Fetching data');
  if (req.method === 'POST') console.log('Creating data');
  next();
});

📥 Understanding the Request Object (`req`)

The first line of an HTTP request is: METHOD PATH PROTOCOL.

Express splits that PATH into two specific parts: Route Parameters and Query Strings.

1. `req.params` (Dynamic Values in the URL)

These are named placeholders you define in your route path. They are part of the URL's structural hierarchy.

Suppose your application has the following route:

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

  console.log(req.params);

});

Notice the :id?

That colon tells Express:

"This part of the URL is dynamic."

Now imagine someone visits:

/users/42

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

Output:

{
  id: "42"
}

When should you use `req.params`?

Whenever you're identifying a specific resource.

Examples:

/users/42
/products/101
/orders/9001

Think of it like a house address.

Without the address, the delivery person doesn't know which house to visit.

Similarly, without an ID, your server doesn't know which user, product, or order you're referring to.

2. `req.query` (Optional Information)

Now consider this URL:

/users?page=2&limit=10

Everything after the ? is called the query string.

Express automatically converts it into:

req.query

Output:

{
  page: "2",
  limit: "10"
}

Unlike route parameters, query parameters are optional.

The same route works perfectly fine without them.

Common use cases

Pagination

/users?page=2

Searching

/users?search=express

Filtering

/products?category=laptops

Sorting

/products?sort=price

💡 Pro Tip: Every value inside req.query is a string. If you need a number, convert it using Number() or parseInt().

`req.headers` (Metadata About the Request)

Headers are key-value pairs sent before the body. They contain metadata about the request, not the actual data itself.

Common headers you will use daily:

Header	Purpose
`Authorization`	Sends credentials (Bearer tokens, Basic Auth).
`Content-Type`	Tells the server how the body is formatted (`application/json`, `multipart/form-data`, `text/plain`).
`Accept`	Tells the server what format the client wants back (`application/json`, `text/html`).
`Cookie`	Sends stored session cookies from the browser.
`User-Agent`	Identifies the client's browser/OS.

Express behavior: Express lowercases all header names.

// Incoming header: Authorization: Bearer abc123
console.log(req.headers.authorization); // "Bearer abc123"
console.log(req.headers['content-type']); // "application/json"

💡 We'll dive much deeper into request headers when we build authentication and authorization systems later in this series.

`req.body` (The Actual Data)

When the client wants to create or update something, it usually sends data inside the request body.

For example:

{
  "name": "Raman",
  "role": "Developer"
}

Express makes this data available through:

console.log(req.body);

Output:

{
  name: "Raman",
  role: "Developer"
}

Simple enough...

Well... almost 😄

By default, Express doesn't know how to read JSON data.

You need to tell it to parse incoming JSON requests by registering the built-in JSON middleware.

app.use(express.json());

Without this middleware:

console.log(req.body);

Output:

undefined

This is probably one of the most common mistakes every beginner and experienced makes.

We'll understand why express.json() is required and how middleware works internally in the Middleware section.

When to use req.body:

POST/PUT/PATCH requests where you are sending structured data (e.g., { "email": "ramanand@zohomail.com", "password": "123" }).
Critical Rule: A GET request cannot have a req.body. If you put a body on a GET request, most servers and proxies will ignore or reject it.

The "Hidden" Request Properties

Express adds a few extra helpful properties to the req object that you will use:

Property	What it gives you
`req.ip`	The IP address of the client.
`req.path`	The URL path without the query string. (e.g., `/users/42/posts`)
`req.hostname`	The domain name (e.g., `mywebsite.com`).
`req.protocol`	`http` or `https`.
`req.cookies`	Requires middleware (`cookie-parser`). Gives you parsed cookies.
`req.signedCookies`	Cookies that have been cryptographically signed to prevent tampering.

So when a request hits your server, the data flows into exclusive zones. They do not overlap.

URL Path → req.params (e.g., /users/:id)
URL Search → req.query (e.g., ?filter=active)
HTTP Headers → req.headers (e.g., Authorization)
HTTP Body → req.body (e.g., { "name": "John" })

💡 Pro Tip: Never put a password or large data in req.params or req.query because URLs are logged by servers and browsers. Always send sensitive data (passwords, credit cards) in the req.body over HTTPS.

Here is how a good developer routes their data:

app.delete('/api/products/:productId', (req, res) => {
  // 1. Identify WHAT to delete (Path param)
  const { productId } = req.params;

  // 2. Identify WHO is deleting (Auth header)
  const userId = req.headers['x-user-id']; // Custom header for internal auth

  // 3. Check for optional admin override (Query param for dev tools)
  const forceDelete = req.query.force === 'true';

  // Logic...
});

📤 Understanding HTTP Response Status Codes

So far, we've seen how a client sends a request to the server.

But what happens after the server processes that request?

It needs to tell the client what happened.

Did everything go well?

Was something missing?

Did the client send invalid data?

Or did the server itself run into a problem?

That's exactly what HTTP status codes are for.

Think of them as the server's way of saying:

"Here's what happened with your request."

🧠 Status Codes are Organized into Families

Instead of remembering dozens of individual status codes, it's much easier to remember their families.
|Status Code | Meaning|
|--|--|
| 2xx | ✅ Success — Everything worked |
| 3xx | 🔄 Redirection — Go somewhere else |
| 4xx | ❌ Client Error — Something is wrong with the request |
| 5xx | 💥 Server Error — Something went wrong on the server |

For most Express applications, you'll spend the majority of your time working with 2xx, 4xx, and 5xx responses.

📊 Which Status Code Should You Return?

Here's a simple cheat sheet that you'll use in almost every REST API.

Request	Success	Common Failure	Why?
GET	`200 OK`	`404 Not Found`	Data was returned successfully. If the requested resource doesn't exist, return `404`.
POST	`201 Created`	`400 Bad Request`	A new resource was created. If the client sends invalid data, return `400`.
PUT	`200 OK` or `204 No Content`	`400 Bad Request`	The existing resource was updated or replaced.
PATCH	`200 OK`	`400 Bad Request`	Part of an existing resource was updated.
DELETE	`204 No Content` or `200 OK`	`404 Not Found`	The resource was deleted. If it doesn't exist, return `404`.

Don't worry if you don't remember all of these right away.

After building a few APIs, these status codes become second nature.

✅ 200 OK

This is the most common status code you'll ever return.

It simply means:

"Your request was successful."

For example:

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

  res.status(200).json([
    {
      id: 1,
      name: "John"
    }
  ]);

});

The server successfully found the users and returned them.

🆕 201 Created

A common beginner mistake is returning 200 OK after creating a new resource.

Technically, it works.

But it's not the best choice.

If your API creates something new, the more appropriate response is:

201 Created

Example:

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

  const user = {
    id: 101,
    ...req.body
  };

  res.status(201).json(user);

});

The response tells the client:

"Your request didn't just succeed—we actually created something."

💡 Pro Tip

Professional APIs often include a Location header pointing to the newly created resource.

res
  .status(201)
  .location("/users/101")
  .json(user);

This makes it easy for clients to immediately fetch the new resource if needed.

🚫 400 Bad Request

This error means:

"I understood your request, but the data you sent is invalid."

Imagine trying to register with:

{
  "email": "not-an-email",
  "password": ""
}

The request reached your server.

Your route executed.

But the data failed validation.

Example:

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

  if (!req.body.email) {

    return res.status(400).json({

      message: "Email is required"

    });

  }
  // Continue creating user...
});

Notice something important.

The server isn't broken.

The client needs to fix the request.

🔍 404 Not Found

This one is probably the easiest to understand.

It simply means:

"The resource you're looking for doesn't exist."

Example:

GET /users/999

If user 999 doesn't exist:

res.status(404).json({

  message: "User not found"

});

Unlike 400, there is nothing wrong with the request format.

The problem is that the requested resource simply doesn't exist.

💥 500 Internal Server Error

This is the status code every developer hopes never reaches production.

It means:

"Something went wrong inside the server."

Maybe:

Database connection failed
Third-party API is down
Unexpected exception occurred
Bug in your code

Example:

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

  try {

    const users = await database.getUsers();

    res.json(users);

  } catch (error) {

    res.status(500).json({

      message: "Something went wrong."

    });

  }

});

Unlike 400, this isn't the client's fault.

The server failed while processing a perfectly valid request.

📤 Understanding the Response Object (`res`)

We've spent quite a bit of time looking at the request object (req)—everything the client sends to our server.

But a conversation isn't complete if only one side talks.

After processing the request, the server needs to send something back.

That's where the Response Object (res) comes in.

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

  // Send a response back to the client

});

Think of it like a conversation.

The browser asks a question.

The server answers it.

Everything the server sends back—whether it's plain text, JSON data, an HTML page, an image, or even an error message—goes through the res object.

Let's look at the methods you'll use most often.

💬 `res.send()` — Send Almost Anything

The simplest way to respond to a client is with res.send().

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

  res.send("Hello, Express!");

});

The browser receives:

Hello, Express!

Simple enough.

But here's the cool part...

res.send() is smart.

It can send:

Strings
HTML
Buffers
Objects
Arrays

For example:

res.send("<h1>Welcome!</h1>");

renders HTML in the browser.

While this:

res.send({
  name: "John"
});

automatically sends JSON.

Even though res.send() can send almost anything, most modern APIs prefer using res.json() when returning JSON data because it makes your intention much clearer.

📦 `res.json()` — Send JSON Responses

Most Express applications today are REST APIs.

And REST APIs almost always communicate using JSON.

Instead of writing:

res.send({
  success: true
});

it's more common to write:

res.json({
  success: true
});

The client receives:

{
  "success": true
}

Behind the scenes, Express automatically does two important things for you:

Converts your JavaScript object into JSON.
Sets the correct response header.

Content-Type: application/json

You don't have to call JSON.stringify() or manually set the content type.

Express takes care of everything.

That's why you'll see res.json() in almost every Express API.

🚦 `res.status()` — Tell the Client What Happened

Sending data is only half the story.

The client also needs to know whether the request succeeded or failed.

That's exactly what res.status() is for.

For example:

res.status(404);

sets the HTTP status code to 404 Not Found.

In practice, you'll almost always chain it with another response method.

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

  // Imagine the user doesn't exist...

  res.status(404).json({

    message: "User not found"

  });

});

The client now receives two things:

Status Code

404 Not Found

Response Body

{
  "message": "User not found"
}

This tells the client not only what happened, but also why it happened.

🔗 Method Chaining

One thing you'll notice in Express is that response methods are often chained together.

For example:

res.status(201).json(user);

res.status(500).send("Internal Server Error");

This works because methods like res.status() return the response object itself, allowing you to immediately call another method.

It makes the code concise and very readable.

🧠 Putting It All Together

Let's build a small example that combines everything we've learned so far.

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

  const user = {

    id: 101,
    ...req.body

  };

  res
    .status(201)
    .json(user);

});

When the client sends:

{
  "name": "Rama",
  "role": "Developer"
}

The server responds with:

Status

201 Created

Body

{
  "id": 101,
  "name": "Rama",
  "role": "Developer"
}

Notice how the response communicates both the result (a new user was created) and the data (the newly created user).

🔥 Middleware

Now we're at the heart of Express.

🔥 Middleware — The Superpower Behind Express

So far, we've learned how a request reaches our Express application and how we can send a response back.

But what if you want to:

Log every incoming request?
Check if a user is authenticated?
Parse JSON data?
Validate incoming requests?
Compress responses?
Handle errors?

Surely you don't want to write the same code inside every single route.

That's exactly the problem middleware solves.

In fact, middleware is one of the biggest reasons Express became so popular.

🤔 What Exactly is Middleware?

At its core, middleware is simply a function that runs between the incoming request and the outgoing response.

Think of it like a security checkpoint at an airport.

Every passenger has to pass through security before boarding the plane.

Similarly, every request can pass through one or more middleware functions before reaching your route handler.

Instead of handling everything inside your routes, you can move common tasks into reusable middleware.

🚦 The Middleware Pipeline — How Every Request Travels Through Express

🧠 Think of Middleware as a Conveyor Belt

Imagine a package moving through a factory.

Before it reaches the customer, it passes through several stations.

Each station performs one specific task and then passes the package to the next station.

Middleware works exactly the same way.

Each middleware performs one job and then hands the request to the next middleware in the chain.

That's the entire middleware pipeline.

🛠️ Anatomy of a Middleware Function

A middleware function always receives three parameters.

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

  console.log(req.method);

  next();

};

Let's understand each one.

Parameter	Purpose
`req`	The incoming request from the client
`res`	The response that will eventually be sent back
`next`	A function that tells Express to continue to the next middleware or route

You've already seenreq and res.

The new character here is next().

And it's arguably the most important function in all of Express.

🚦 Understanding `next()`

Think of next() as saying:

"I'm done with my work. Let the next person continue."

Let's look at a simple example.

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

  console.log("📥 Request received");

  next();

};

Every time a request arrives:

The message is logged.
next() is called.
Express moves on to the next middleware (or the route handler).

Simple.

But here's where many get stuck...

😱 What Happens If You Forget `next()`?

Suppose you accidentally write this:

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

  console.log("📥 Request received");

  // Oops...
  // Forgot to call next()

};

Now imagine a request comes in.

The logger runs.

It prints the message.

And then...

Nothing.

Express has no idea what to do next.

It keeps waiting for the middleware to either:

send a response, or
pass control to the next middleware.

Since neither happened, the request gets stuck forever.

From the browser's perspective, it looks like this:

Loading...
Loading...
Loading...
Loading...

The page never finishes loading because Express is still waiting.

This is one of the most common "silent bugs" beginners encounter.

Your server doesn't crash.

It doesn't throw an error.

The request simply hangs.

Whenever this happens, the first thing to check is:

"Did I forget to call next() or send a response?"

🧩 Why Does This Happen?

Express processes middleware like people standing in a queue.

Each middleware has exactly two responsibilities:

Option 1: Pass the request forward

next();

This tells Express:

"I'm done. Continue processing the request."

Option 2: End the request

For example:

res.send("Access Denied");

res.json({
  message: "Success"
});

res.status(401).json({
  message: "Unauthorized"
});

Once a response is sent, the request lifecycle ends.

No other middleware or routes will run after that.

🧩 Types of Middleware

Not every middleware behaves the same way.

Some run for every request.

Some only run on specific routes.

Some are built into Express.

Others come from third-party packages.

Let's look at each type.

🌍 Application Middleware

Application middleware runs for every incoming request.

It's registered using app.use().

app.use((req, res, next) => {

  console.log("📥 Incoming request");

  next();

});

Now every request is logged.

Whether someone visits:

/users

/products/101

this middleware runs first.

Application middleware is commonly used for:

Logging
Authentication
Request parsing
Security
Rate limiting

Think of it as the building's main entrance.

Everyone passes through it.

🎯 Route Middleware

Sometimes you don't want middleware to run for every request.

Maybe only authenticated users should access the dashboard.

Instead of protecting every route, you can protect just one.

app.get(
  "/dashboard",
  authMiddleware,
  dashboardController
);

The execution flow looks like this:

If authentication fails, the controller never executes.

This is one of the reasons middleware is so powerful.

It lets you keep your route handlers clean by separating reusable logic.

🛠️ Built-in Middleware

Some middleware is already included with Express.

You don't need to install anything.

You simply use it.

📦 `express.json()`

Parses incoming JSON requests.

app.use(express.json());

Without this middleware:

console.log(req.body);

returns:

undefined

You've already seen this one earlier.

It's probably the first middleware every Express developer uses.

📝 `express.urlencoded()`

Parses data submitted from traditional HTML forms.

app.use(
  express.urlencoded({
    extended: true
  })
);

Without it, form data won't appear inside req.body.

📂 `express.static()`

Serves static files like:

HTML
CSS
JavaScript
Images
Fonts

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

Now a file like:

public/logo.png

becomes available at:

http://localhost:3000/logo.png

No route required.

Express serves it automatically.

📦 Third-Party Middleware

The Express community has built thousands of reusable middleware packages.

Instead of solving common problems yourself, you simply install them.

Some of the most popular ones include:

🛡️ Helmet

app.use(helmet());

Adds several HTTP security headers to make your application safer.

🌍 CORS

app.use(cors());

Allows your frontend and backend to communicate even when they're running on different domains or ports.

We'll cover CORS in detail later because it's an important topic on its own.

📝 Morgan

app.use(morgan("dev"));

Logs every incoming request.

Example output:

GET /users 200 18 ms
POST /login 401 7 ms

Very useful during development.

🔐 Real-World Example — Authentication Middleware

Let's build something you'll see in almost every production Express application.

Suppose certain routes should only be accessible to logged-in users.

Instead of writing authentication logic inside every route, we move it into middleware.

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

  const token = req.headers.authorization;

  if (!token) {

    return res.status(401).json({

      message: "Unauthorized"

    });

  }

  next();

};

Now protecting a route becomes incredibly simple.

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

    res.send("Welcome to your profile!");

  }
);

Let's see what happens when someone visits this route.

Without an Authorization Header

The request stops immediately.

The route handler never executes.

With a Valid Authorization Header

This is exactly how JWT authentication works in real-world Express applications.

We'll build one from scratch later in this series.

📚 Middleware Executes in Registration Order

If you have this question in your mind

"In what order does Express execute middleware?"

The answer is simple.

Top to bottom.

Consider this example.

app.use(middlewareA);

app.use(middlewareB);

app.get("/", handler);

A request to / produces:

middlewareA
middlewareB
handler

Express doesn't try to optimize or reorder middleware.

It executes them exactly in the order you register them.

This is why you'll usually see middleware registered near the top of an Express application.

const express = require("express");

const app = express();

app.use(express.json());

app.use(cors());

app.use(morgan("dev"));

// Routes come afterwards...

If you register middleware after your routes, those routes won't pass through it.

Order matters.

💥 Error Handling Middleware

There's one special type of middleware that behaves differently.

Instead of three parameters:

(req, res, next)

it has four.

(err, req, res, next)

That extra err parameter tells Express:

"This middleware is responsible for handling errors."

Here's a simple example.

app.use((err, req, res, next) => {

  console.error(err);

  res.status(500).json({

    message: "Internal Server Error"

  });

});

Whenever an error is passed to next(error) or thrown inside your application, Express skips all normal middleware and jumps directly to the nearest error-handling middleware.

This keeps your application from crashing and allows you to send a consistent error response to the client.

I'll dedicate an entire article to error handling later in this series because it's a fundamental part of building reliable production APIs.

🧠 The One Rule You'll Never Forget

If there's one thing you should remember about middleware, let it be this:

Every middleware must do exactly one of two things:

Call next() to continue processing the request.
Send a response to end the request.

If it does neither, Express has nowhere to go, and the request hangs forever.

Once this simple rule clicks, the entire Express middleware system becomes much easier to understand, and you'll be able to read almost any Express application with confidence.

🤯 What Broke When I First Learned Middleware

Forgot `next()`

Browser loading forever.

Registered middleware after routes

Middleware never executed.

Forgot `express.json()`

req.body was undefined.

Every Express developer has done these at least once 😄

🎯 Key Takeaways

Express is built around a middleware pipeline.
Every request follows the same lifecycle.
Middleware executes in registration order.
next() moves execution forward.
req contains incoming data.
res controls outgoing data.
Understanding middleware makes debugging dramatically easier.

📢 What’s Next?

In the next article we'll cover:

Express Router
Route Parameters
REST APIs
CRUD Operations
Project Structure
MVC Architecture

Once you understand Router and Middleware together, Express starts feeling ridiculously elegant 🚀

💬 Your Turn

What confused you most when learning Express?

Middleware?
next()?
req.body?
Route order?

Let me know in the comments 👇

📣 Call To Action

If this article helped you:

⭐ Bookmark it
🔁 Share it with a fellow developer
🚀 Build a small Express API today
👨‍💻 Follow for more Node.js and backend deep dives

🚀 Getting Started with Node.js – from “What is this?” to your first web server

Ramanand Thakur — Wed, 03 Jun 2026 13:01:13 +0000

Node.js lets us run JavaScript outside the browser. In this guide, we’ll install Node, learn the terminal, explore npm, build a real web server, understand event-driven programming, and serve static files — all before jumping into Express.js 🔥

🧠 Why Node.js feels magical

In the previous article, we mentioned that JavaScript was designed to run only in browsers. Then Node.js came along, and suddenly everyone was like, “Hold on… JavaScript can run on servers too?!”

Until then, JavaScript meant:

button clicks
animations
form validation
frontend headaches 😅

But with Node.js, suddenly JavaScript could:

read files
create APIs
talk to databases
stream videos
run backend servers

In this article, I’ll walk you through the exact beginner path I wish someone had shown me earlier.

By the end, you’ll:

✅ Install Node.js
✅ Understand the terminal without fear
✅ Learn npm properly
✅ Build your own Node server
✅ Understand routing
✅ Serve HTML/CSS files
✅ Be fully ready for Express.js

📌 Prerequisites

You only need:

Basic JavaScript knowledge
A laptop 🙂
Node.js v20+ recommended
☕ Coffee (strongly recommended)

🌍 What Exactly is Node.js?

Node.js is a JavaScript runtime built on Chrome’s V8 engine.

That means:

It allows JavaScript to run outside the browser.

Instead of running only inside Chrome or Firefox, JavaScript can now run directly on your computer or server.

📊 Browser JavaScript vs Node.js

💻 Getting Node.js

🟢 Step 1: Download Node

Visit:

Node.js Official Website

Download the LTS version.

💡 Production note: Always prefer the LTS (Long Term Support) version for stability.

🟢 Step 2: Verify Installation

Open terminal and run:

node -v

Example output:

v20.11.0

Now check npm:

npm -v

Example:

10.2.4

Boom 💥 Node installed successfully.

🖥️ Using the Terminal

We all were scared of it initially 😄

Most beginners avoid the terminal initially.

I did too.

Huge mistake.

The terminal is basically your direct communication line with the operating system.

Think of it like this:

GUI	Terminal
Clicking buttons	Typing commands
Slower	Faster
Beginner friendly	Developer powerful

📂 Essential Terminal Commands

Windows

Use:

PowerShell
Windows Terminal

macOS/Linux

Use:

Terminal app

📌 Most Useful Commands

# Show current folder
pwd

# List files
ls

# Change folder
cd folder-name

# Create folder
mkdir my-project

# Create file
touch app.js

📊 Terminal Workflow

🛠️ Editors (VS Code or Claude)

You technically can write Node code in Notepad.

But please don’t torture yourself 😭.

🟦 VS Code (Recommended)

Visual Studio Code

Why developers love it:

Fast
Free
Great extensions
Git integration
Built-in terminal
Excellent Node support

🔌 Extensions I Recommend

Extension	Why
ESLint	Catch JavaScript mistakes
Prettier	Auto formatting
Thunder Client	API testing
GitLens	Git superpowers

🤖 Claude Editor

Many developers also use:

Claude AI

Especially for:

debugging help
refactoring
documentation generation
learning concepts faster
vibe coding (We'll discuss this in detail in future articles)

But honestly?

VS Code + Node is still the gold standard for most beginners.

📦 Understanding npm

npm stands for:

Node Package Manager

This is where Node becomes insanely powerful.

npm lets you install reusable packages instead of reinventing the wheel every time.

🧱 Create Your First Project

mkdir node-demo
cd node-demo

Initialize project:

npm init -y

This creates:

package.json

📄 What is package.json?

Think of it like:

The Aadhaar card or identity card of your project 😄

It contains:

project name
dependencies
scripts
version
metadata

📌 Example package.json

{
  "name": "node-demo",
  "version": "1.0.0",
  "main": "app.js"
}

📊 How npm Works

🚀 A Simple Web Server with Node.js

Now the fun part begins 🔥

👋 Hello World Server

Create:

app.js

✅ Minimal Node Server

// Node.js v20

// Import Node's built-in HTTP module
const http = require('http');

// Create server
const server = http.createServer((request, response) => {

  // Send HTTP status code
  response.writeHead(200, {
    'Content-Type': 'text/plain'
  });

  // Send response body
  response.end('Hello World from Node.js 🚀');
});

// Start listening on port 3000
server.listen(3000, () => {

  // Callback runs once server starts
  console.log('Server running at http://localhost:3000');

});

▶️ Run the Server

node app.js

Visit:

http://localhost:3000

And there it is 🎉

Your first Node web server.

⚡ Understanding Event-Driven Programming

This is THE core Node concept.

And honestly?

This is where many folks get confused initially.

🧠 Traditional Programming

Traditional systems often wait for one task to finish before moving to the next.

Like standing in a railway booking queue 🚉.

One person at a time.

🚀 Node’s Event-Driven Model

Node works differently.

Instead of blocking everything:

it listens for events
processes callbacks
handles async tasks efficiently

📊 Event Loop Explained

📌 Simple Event Example

// Node.js Events Module

const EventEmitter = require('events');

// Create event emitter instance
const emitter = new EventEmitter();

// Listen for custom event
emitter.on('orderPlaced', () => {

  console.log('🍕 Pizza order received');

});

// Emit event
emitter.emit('orderPlaced');

Output:

🍕 Pizza order received

🧭 Routing in Node.js

Routing means:

Sending different responses for different URLs.

Example:

URL	Response
`/`	Home page
`/about`	About page
`/contact`	Contact page

✅ Basic Routing Example

// app.js

const http = require('http');

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

  // Homepage route
  if (req.url === '/') {

    res.writeHead(200, {
      'Content-Type': 'text/plain'
    });

    res.end('🏠 Welcome Home');

  }

  // About page route
  else if (req.url === '/about') {

    res.writeHead(200, {
      'Content-Type': 'text/plain'
    });

    res.end('ℹ️ About Us');

  }

  // Fallback route
  else {

    res.writeHead(404, {
      'Content-Type': 'text/plain'
    });

    res.end('❌ Page Not Found');

  }

});

// Start server
server.listen(3000, () => {
  console.log('Server started');
});

📊 How Routing Works

📂 Serving Static Resources

Static resources include:

HTML
CSS
JavaScript
Images

Without this, websites would look like 1998 😅.

📁 Project Structure

project/
│
├── app.js
├── public/
│   ├── index.html
│   └── style.css

✅ Serve HTML File

// Node.js v20

const http = require('http');
const fs = require('fs');

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

  // Read HTML file
  fs.readFile('./public/index.html', (error, data) => {

    // Handle file read errors
    if (error) {

      res.writeHead(500);

      res.end('Internal Server Error');

      return;
    }

    // Send HTML response
    res.writeHead(200, {
      'Content-Type': 'text/html'
    });

    res.end(data);

  });

});

server.listen(3000);

📄 Example HTML

<!DOCTYPE html>
<html>

<head>
  <title>Node Demo</title>
</head>

<body>

  <h1>🚀 Node.js Server</h1>

</body>
</html>

🎨 Serve CSS File

// Simplified CSS serving example

if (req.url === '/style.css') {

  fs.readFile('./public/style.css', (err, data) => {

    res.writeHead(200, {
      'Content-Type': 'text/css'
    });

    res.end(data);

  });

}

🤯 What Broke When I Tried This

TBH, many things 😂

❌ Mistake 1: Wrong File Path

ENOENT: no such file or directory

✅ Fix

Always verify folder structure carefully.

❌ Mistake 2: Port Already in Use

EADDRINUSE

✅ Fix

Another app is using the same port.

Simply, change the port number. (3000 to something else which is not getting used 😄)

❌ Mistake 3: Browser Keeps Loading Forever

Usually happens because:

res.end()

was forgotten.

📈 Why Express.js Was Needed

After writing enough raw Node servers, developers realized:

“Dude… this is becoming repetitive.”

Things became messy quickly:

manual routing
manual headers
repetitive file handling
middleware chaos

That’s exactly why Express.js became popular.

📊 Raw Node vs Express

Express dramatically reduced boilerplate code.

☕ Caffeine Scale

Topic	Complexity
Installing Node	☕
npm basics	☕☕
Routing	☕☕
Event loop	☕☕☕☕

🎯 Onward to Express.js

Now you understand:

✅ Node installation
✅ Terminal basics
✅ npm
✅ HTTP servers
✅ Event-driven programming
✅ Routing
✅ Static files

You’re officially ready for:

🚀 Express.js

But don’t worry — if you missed anything, we’ll come back to some of these topics individually and go way deeper 🚀

And trust me…

Once you use Express routing after raw Node routing, it feels like upgrading from manual gear driving to automatic 😄

📌 Key Takeaways

Node.js lets JavaScript run outside browsers
npm powers the massive Node ecosystem
Node uses event-driven architecture
You can build web servers with built-in modules
Routing and static file serving are fundamental backend concepts
Express simplifies all of this beautifully

📢 What’s Next?

In the next article we’ll cover:

Scaffolding
Installing Express
Request/response lifecycle
Middleware

👉 Continue to Express.js Guide

💬 Your Turn

What confused you most when learning Node?

npm?
terminal?
async programming?
routing?

And did you also use incorrect file path at least once? 😅

📣 Call To Action

If this article helped you:

⭐ Bookmark it
🔁 Share with a beginner developer
🚀 Build your own tiny Node server today
👨‍💻 Follow for more backend deep dives

🚀 Introduction to Express.js – the framework that changed Node forever

Ramanand Thakur — Tue, 26 May 2026 12:34:00 +0000

Express.js made backend development in JavaScript ridiculously simple. Before Express, building APIs in Node felt like assembling IKEA furniture without the manual 😅.

🧠 The JavaScript Revolution

There was a time when JavaScript lived only inside browsers.

Frontend? JavaScript.
Backend? Mostly PHP, Java, Python, Ruby, or .NET.

Then came Node.js in 2009 and everything changed.

Suddenly, developers could write JavaScript on both:

🖥️ Client side (browser)
🌐 Server side (backend)

Yes, this was a massive shift.

Teams no longer needed separate frontend and backend language expertise. One language could handle:

UI rendering
API development
Real-time chat apps
Streaming
File handling
Even CLI tools

And this is where Express.js entered like a Bollywood hero in slow motion 🎬.

⚡ Introducing Express

Express.js is a lightweight web framework built on top of Node.js.

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

Express gives you:

Steering wheel
Dashboard
Brakes
Air conditioning
And sane defaults 😄

Without Express, building APIs in pure Node means manually handling:

Routing
Headers
Request parsing
Response formatting
Middleware chaining

Express simplifies all of that.

📦 Installing Express

Prerequisites

Node.js v18+
Basic JavaScript knowledge (Watch any quick 30 minutes tutorial on YT)
npm installed
☕ 2 cups of coffee

🛠️ Your First Express Server

mkdir express-demo
cd express-demo

npm init -y
npm install express

Now create server.js.

// Node v20 + Express 4

const express = require('express');

const app = express();

// Route handler
app.get('/', (req, res) => {
  res.send('Hello from Express 🚀');
});

// Start server
app.listen(3000, () => {
  console.log('Server running on http://localhost:3000');
});

Run it:

node server.js

Open browser:

http://localhost:3000

And boom 💥 — backend server ready in less than 10 lines.

🌍 Server-side vs Client-side Applications

This is where many beginners get confused.

Let’s simplify it.

🖥️ Client-side Applications

Client-side apps run in the browser.

Examples:

React
Angular
Vue

Responsibilities:

Rendering UI
Handling clicks
Animations
Calling APIs

🌐 Server-side Applications

Server-side apps run on servers.

Responsibilities:

Database operations
Authentication
Business logic
API responses
Security

📊 How They Talk To Each Other

This separation is the backbone of modern web apps.

📜 A Brief History of Express

Express was created by TJ Holowaychuk around 2010.

Back then, Node.js was still young.

Developers loved Node’s speed, but building servers directly with Node’s http module was painful.

Here’s how raw Node looked:

// Pure Node.js HTTP server 😵

const http = require('http');

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

    res.end('Hello World');
  }
});

server.listen(3000);

Not terrible… until your app grows to 50 routes and middleware chains.

Express solved that elegantly.

⚔️ Node.js vs Traditional Web Servers

Before Node.js, most web servers worked like this:

🧵 Traditional Web Servers (Apache, PHP, Java)

Request Flow

Every request often created:

New thread
More memory usage
Context switching overhead

Works fine… until traffic explodes 🚦.

⚡ Node.js Architecture

Request Flow

Node uses:

Single-threaded event loop
Non-blocking I/O
Async processing

This is why Node became insanely popular for:

Real-time apps
APIs
Streaming
Chat systems
Notification services

☕ Caffeine Scale

Topic	Complexity
Basic Express routes	☕
Middleware	☕☕
Event loop internals	☕☕☕☕

🌱 The Node Ecosystem

One of Node’s biggest strengths is the ecosystem.

The package manager npm exploded in popularity because developers could share reusable libraries instantly.

Today there are millions of packages.

Some famous ones:

Package	Purpose
`express`	Web framework
`mongoose`	MongoDB ORM
`socket.io`	Real-time communication
`dotenv`	Environment variables
`jsonwebtoken`	JWT authentication
`nodemon`	Auto restart during development

📄 Licensing

Express is open-source software released under the MIT License.

That means:

✅ Free to use
✅ Free to modify
✅ Free for commercial projects

This openness helped Express spread rapidly across startups and enterprises alike.

Even huge companies adopted it because there were no painful licensing restrictions.

❌ Common Beginner Mistakes

(Try these fixes you face issue running your first express backend)

1️⃣ Forgetting Middleware

// ❌ req.body will be undefined

app.post('/login', (req, res) => {
  console.log(req.body);
});

✅ Correct Version

// Express 4.18+

app.use(express.json());

app.post('/login', (req, res) => {
  console.log(req.body);
  res.send('Body parsed correctly');
});

2️⃣ Blocking the Event Loop

// ❌ Very dangerous for performance

while(true) {
  // Infinite blocking loop 💥
}

Node works best when operations stay async.

📊 Express vs Traditional Backend Frameworks

Feature	Express.js	Traditional Java Frameworks
Language	JavaScript	Java
Performance	Excellent for I/O	Excellent for CPU-heavy work
Learning Curve	Easy	Moderate
Boilerplate	Minimal	Often verbose
Real-time Support	Excellent	Good
Startup Speed	Fast	Slower

🎯 Conclusion

Express.js became popular because it made backend development:

Simpler
Faster
More readable
More JavaScript-friendly

Key takeaways:

🚀 Express simplified Node.js web development
🌐 Node introduced a non-blocking server model
📦 npm created one of the biggest developer ecosystems ever
⚡ Express is ideal for APIs and real-time applications
🔓 Open-source licensing accelerated adoption worldwide

And honestly? Once you build your first Express API, going back to raw HTTP servers feels like manually washing clothes after buying a washing machine 😄.

🔥 What’s Next?

In the next part, we’ll dive deeper in:

Using the Terminal
Using Editor
Using NPM (Node Package Manager)
Event-Driven Programming
Routing
Serving static resources

👉 Continue to Getting Started with Node.js Guide

💬 Your Turn

What was your first backend framework?

PHP? Django? Spring Boot? Express?

And have you ever crashed a production server accidentally? 😅

📢 Call To Action

If this helped you understand Express better:

⭐ Share it with another developer
🔁 Bookmark for revision
🚀 Try building a tiny REST API today
👨‍💻 Follow for more deep-dive backend content

Useful Android Studio Plugins

Ramanand Thakur — Sun, 08 Jan 2023 00:28:55 +0000

If you want to learn how to create Android apps, Android Studio is where your search will end. It is a platform where you can create Android apps for Android phones, tablets, Android Wear(Smartwatch/Fitness), and Android TV. Kotlin or Java may be used to create the backend of Android applications, while XML can be used to create the user interface (UI) on the front end.

1. CodeGlance

CodeGlance is a type of minimap of the full code that enables you to quickly inspect an entire code block. When the CodeGlance feature is enabled, the entire code is displayed to the side of the screen in minimap style, allowing you to rapidly go to the required area of the code by choosing it from the CodeGlance box.

2. Butterknife Zelezny

ButterKnife Zelezny is an android studio plug-in that lets you generate ButterKnife injections from specific layout XML. It is a very simple plug-in, hence generates Butterknife view injections with just one-click.
The major goal is to increase coding efficiency and make it simple for developers to instantly produce the code of the control binding view.

3. Vector Drawable Thumbnails

We often need to rebuild the project in order to see a vector drawable XML file. We can quickly preview all of the vector drawables using Vector Drawable Thumbnails.

4. Rainbow Brackets

5. Android Drawable Preview

When creating an Android app, you'll need a variety of drawable components. When working on a large project, it might be difficult to recall which drawable you used. Figuring this out takes a lot of time and effort.
This plugin solves this issue by replacing the project view's default file icons with previews of the drawable you've used. You can also browse through the folder to know which all drawables has been used.

6. The Name That Color

The Name That Color plugin in Android Studio will name the colour you currently have copied to your clipboard and provide the name of the colour that is the closest match.

7. String Manipulation

You can do everything with String Manipulation, including toggle cases, switch between camel, snake, and kebab cases, increment duplicates, sort, escape/unescape HTML, Java, SQL, PHP, and XML strings, and run filter operations like grep.

8. ADB Idea

It enables shortcuts for a number of emulator features that are often quite time-consuming, such as clearing the app's data, removing it from the system, or starting the debugger.

9. Power Mode II

Sometimes, coding can get tedious. but not while this plugin is activated. Your fingers are spitting fire and trembling as you read this. Every time anything gets dull to continue, I personally like to use this addon. Start coding while your favourite music is playing. It gets even better when your music syncs with the shaking effect.

10. Tabnine

This article would have been incomplete without mentioning a powerful tool like Tabnine. It is trained on over two million GitHub files and supports 20 programming languages. It looks for patterns in the training data set that may be used to predict the next "token". The use of tabnine speeds up development and helps get eliminate those annoying errors that keep popping up in your code.

Always keep in mind that adding too many plugins to your IDE won't actually speed up your process. Instead, it can substantially reduce the speed of your Android Studio. As a last recommendation, I'd advise choosing a handful of these plugins and experimenting with it and integrating them during your regular work. And continue with it only after noticeable improvement.

DEV Community: Ramanand Thakur

🚀 Express.js Fundamentals – Understanding Request/Response Lifecycle and Middleware

🎯 What You'll Learn

📌 Prerequisites

🏗️ What is Scaffolding?

🌐 Understanding the Request/Response Lifecycle

🛫 Think of It Like Airport Security

📊 Lifecycle Overview

🔥 What Happens Internally?

Stage 1: Express Creates req and res

Stage 2: Middleware Executes

Stage 3: Route Matching

Stage 4: Business Logic Runs

Stage 5: Response Sent

What is an HTTP Request?

HTTP Request Types (The Methods)

📥 Understanding the Request Object (req)

1. req.params (Dynamic Values in the URL)

When should you use req.params?

2. req.query (Optional Information)

Common use cases

req.headers (Metadata About the Request)

💡 We'll dive much deeper into request headers when we build authentication and authorization systems later in this series.

req.body (The Actual Data)

The "Hidden" Request Properties

📤 Understanding HTTP Response Status Codes

🧠 Status Codes are Organized into Families

📊 Which Status Code Should You Return?

✅ 200 OK

🆕 201 Created

💡 Pro Tip

🚫 400 Bad Request

🔍 404 Not Found

💥 500 Internal Server Error

📤 Understanding the Response Object (res)

💬 res.send() — Send Almost Anything

📦 res.json() — Send JSON Responses

🚦 res.status() — Tell the Client What Happened

🔗 Method Chaining

🧠 Putting It All Together

🔥 Middleware

🔥 Middleware — The Superpower Behind Express

🤔 What Exactly is Middleware?

🚦 The Middleware Pipeline — How Every Request Travels Through Express

🛠️ Anatomy of a Middleware Function

🚦 Understanding next()

😱 What Happens If You Forget next()?

🧩 Why Does This Happen?

Option 1: Pass the request forward

Option 2: End the request

🧩 Types of Middleware

🌍 Application Middleware

🎯 Route Middleware

🛠️ Built-in Middleware

📦 express.json()

📝 express.urlencoded()

📂 express.static()

📦 Third-Party Middleware

🛡️ Helmet

🌍 CORS

📝 Morgan

🔐 Real-World Example — Authentication Middleware

Without an Authorization Header

With a Valid Authorization Header

📚 Middleware Executes in Registration Order

💥 Error Handling Middleware

🧠 The One Rule You'll Never Forget

🤯 What Broke When I First Learned Middleware

Forgot next()

Registered middleware after routes

Forgot express.json()

🎯 Key Takeaways

📢 What’s Next?

💬 Your Turn

📣 Call To Action

🚀 Getting Started with Node.js – from “What is this?” to your first web server

🧠 Why Node.js feels magical

📌 Prerequisites

🌍 What Exactly is Node.js?

📊 Browser JavaScript vs Node.js

📥 Understanding the Request Object (`req`)

1. `req.params` (Dynamic Values in the URL)

When should you use `req.params`?

2. `req.query` (Optional Information)

`req.headers` (Metadata About the Request)

`req.body` (The Actual Data)

📤 Understanding the Response Object (`res`)

💬 `res.send()` — Send Almost Anything

📦 `res.json()` — Send JSON Responses

🚦 `res.status()` — Tell the Client What Happened

🚦 Understanding `next()`

😱 What Happens If You Forget `next()`?

📦 `express.json()`

📝 `express.urlencoded()`

📂 `express.static()`

Forgot `next()`

Forgot `express.json()`