What actually happens after a request hits an Express server?

I've used app.use(), app.get(), middleware, and next() in countless projects. I knew how to use them, but not exactly how they worked together behind the scenes.

At first, I assumed Express somehow "magically" knew which route to execute.

But the more I explored, the more I realized there isn't any magic.

Express follows a surprisingly simple process:

• It receives the request from Node.js.

• It walks through a stack of middleware and routes.

• Each middleware decides whether to pass the request to the next layer using next().

• Once a matching route sends a response, the request lifecycle ends.

Understanding this completely changed how I think about middleware, routing, and debugging Express applications.

In this blog, we'll trace the complete journey of a request—from the moment it reaches the Node.js HTTP server to the moment a response is sent back to the client. Along the way, we'll uncover how Express internally handles middleware, route matching, and the request-response lifecycle.

Let's dive in. 🚀

Express.js Is Built on Top of Node.js

Before we understand how Express handles requests, we need to answer one important question:

Who receives the HTTP request first—Node.js or Express?

The answer is Node.js.

Express doesn't create its own web server. Instead, it uses Node.js's built-in http module under the hood.

When we write:

const express = require("express");

const app = express();

app.listen(3000);

It looks like Express is creating the server for us.

But internally, it's conceptually doing something similar to this:

const http = require("http");

const server = http.createServer(app);

server.listen(3000);

The important thing to notice here is that app is actually a function.

Whenever a client sends a request, Node.js creates two objects:

• req → Contains all information about the incoming request.

• res → Used to send a response back to the client.

Node.js then simply calls the Express application like this:

app(req, res);

At this point, Express takes control of the request.

So the flow looks like this:

Browser
   │
HTTP Request
   │
   ▼
Node.js HTTP Server
   │
Creates req & res
   │
   ▼
app(req, res)
   │
   ▼
Express starts processing the request

This is the first important concept to remember:

Node.js receives every HTTP request first. Express simply takes that request and decides which middleware and route handler should process it.

How Express Stores Middleware and Routes

Now that we know Node.js passes every request to Express, the next question is:

How does Express know which middleware or route to execute?

The answer is surprisingly simple.

Whenever you register a middleware or a route, Express doesn't execute it immediately. Instead, it stores it in an internal stack (or list).

For example:

app.use(logger);

app.use(auth);

app.get("/users", getUsers);

app.post("/users", createUser);

Nothing runs when this code is executed.

Express simply remembers these registrations in the order they were added.

Conceptually, you can think of it like this:

Express Router Stack

1. logger middleware
2. auth middleware
3. GET /users
4. POST /users

This order is very important.

Express always starts from the top of the stack and moves downward until it finds a matching middleware or route.

Imagine a client sends this request:

GET /users

Express starts scanning its stack:

Incoming Request

        │
        ▼
1. logger
        │
        ▼
2. auth
        │
        ▼
3. GET /users
        │
        ▼
4. POST /users

Let's see what happens:

• logger matches → execute it.

• It calls next() → move to the next layer.

• auth matches → execute it.

• It calls next() → continue.

• GET /users matches both the path and HTTP method → execute the route handler.

• The handler sends a response.

• Request processing ends.

Notice something interesting.

Express isn't searching your files or folders.

It isn't looking for a function named getUsers.

It simply walks through the stack one layer at a time, in the exact order you registered everything.

That's why the order of middleware and routes matters so much.

For example:

app.use(logger);
app.get("/users", getUsers);

The logger runs before the route.

But if you accidentally reverse them:

app.get("/users", getUsers);

app.use(logger);

The route may send the response before the logger ever gets a chance to run.

This is why you'll often see middleware registered near the top of an Express application and routes defined afterwards.

In simple terms:

Express works like a person reading a checklist from top to bottom. For every incoming request, it checks each registered middleware and route in order until the request is handled.

Understanding next() — The Heart of Express Middleware

Now we know that Express walks through its internal stack one layer at a time.

But here's the next question:

How does Express know when to move from one middleware to the next?

The answer is a single function:

next()

Think of next() as saying:

"I'm done with my work. Please continue to the next matching middleware or route."

Let's look at a simple middleware:

function logger(req, res, next) {
    console.log(`${req.method} ${req.url}`);

    next();
}

When a request comes in:

GET /users

Here's what happens:

1. Express executes the logger middleware.

2. It prints:

GET /users

1. Then it reaches:

next();

At this point, Express moves to the next layer in its stack.

The flow looks like this:

Request
   │
   ▼
Logger Middleware
   │
 next()
   ▼
Auth Middleware
   │
 next()
   ▼
Route Handler

What if we don't call next()?

Suppose our middleware looks like this:

function logger(req, res, next) {
    console.log(`${req.method} ${req.url}`);
}

Notice that we never call next().

Now when a request arrives:

Request
   │
   ▼
Logger Middleware
   │
   ✖

Express has no idea what to do next.

It doesn't automatically move to the next middleware.

It simply waits.

From the browser's perspective, the request keeps loading until it eventually times out.

That's why every middleware should do one of these two things:

1. Pass control to the next layer:

next();

1. End the request by sending a response:

res.send("Done");

or

res.json(data);

Once a response is sent, the request-response cycle is complete, and Express stops processing any further layers.

A Real Example: Authentication Middleware

Authentication middleware is one of the best examples of how next() works.

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

    if (!token) {
        return res.status(401).send("Unauthorized");
    }

    next();
}

If the user is not authenticated:

Request
   │
   ▼
Logger ✅
   │
   ▼
Auth ❌
   │
401 Unauthorized

The route handler is never executed.

If the user is authenticated:

Request
   │
   ▼
Logger ✅
   │
   ▼
Auth ✅
   │
 next()
   ▼
Route Handler ✅
   │
   ▼
Response

Key Takeaway

next() is what connects every middleware together.

Without it, Express cannot continue to the next layer.

You can think of middleware as a relay race—each runner must pass the baton (next()) to the next runner. If someone doesn't pass the baton, the race ends there.

How Express Matches Routes

Now that we understand how next() moves a request through the middleware stack, let's answer another important question:

How does Express know which middleware or route matches the incoming request?

The answer depends on what you registered.

When Express reaches a layer in its stack, it checks two things:

1. Does the path match?

2. Does the HTTP method match? (Only for routes like app.get(), app.post(), etc.)

Let's understand this with examples.

app.use() — Prefix Matching

Suppose you register a middleware like this:

app.use("/users", logger);

Now imagine these requests arrive:

GET /users
GET /users/1
POST /users
PUT /users/profile

Will the middleware run?

✅ Yes, for all of them.

Why?

Because app.use() performs prefix matching.

As long as the request path starts with /users, the middleware is executed.

You can think of it like this:

/users
   │
   ├── /users
   ├── /users/1
   ├── /users/profile
   └── /users/settings

Every request under /users passes through this middleware.

This is why app.use() is commonly used for:

• Authentication

• Logging

• Request Validation

• CORS

• Rate Limiting

These are concerns that apply to multiple routes, not just one.

app.get() — Exact Route + HTTP Method

Now let's register a route:

app.get("/users", getUsers);

When a request comes in:

GET /users

Express checks:

• Path = /users ✅

• Method = GET ✅

Both match, so the route handler runs.

Now consider:

GET /users/1

Path doesn't match exactly.

So Express skips this route and continues searching.

Similarly:

POST /users

The path matches, but the HTTP method is different.

Again, this route is skipped.

app.all() — Exact Route, Any HTTP Method

Now suppose we write:

app.all("/users", handler);

Unlike app.get(), Express doesn't care about the HTTP method.

These requests will all match:

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

However:

GET /users/1

❌ This still won't match because app.all() also performs exact path matching.

The only difference is that it accepts every HTTP method.

Visualizing the Difference

Imagine these registrations:

app.use("/users", logger);

app.get("/users", getUsers);

app.all("/admin", adminHandler);

Now look at how different requests are handled:

Why This Design?

Think about an authentication middleware.

You don't want to write:

app.get("/users", auth);

app.post("/users", auth);

app.put("/users", auth);

app.delete("/users", auth);

Instead, you simply write:

app.use("/users", auth);

Now every request under /users is automatically protected.

That's the power of middleware.

Key Takeaway

Express doesn't magically know which function to execute.

For every incoming request, it walks through its stack and checks:

• Does the path match?

• If it's a route, does the HTTP method match?

If the answer is yes, Express executes that layer.

If not, it simply moves to the next one.

This simple matching mechanism is what powers routing in Express.

How Express Walks Through the Stack

At this point, you might be wondering:

How does Express know which middleware to execute next?

Internally, Express maintains an index (or pointer) while traversing its router stack.

Imagine you registered the following:

app.use(logger);

app.use(auth);

app.get("/users", getUsers);

app.post("/users", createUser);

Express stores them in order:

Index   Layer

0       logger
1       auth
2       GET /users
3       POST /users

Now suppose a request arrives:

GET /users

Express starts with:

currentIndex = 0

It executes the first layer:

0 → logger

Inside the middleware:

function logger(req, res, next) {
    console.log("Logging request...");
    next();
}

When next() is called, Express simply increments its internal pointer.

currentIndex = 1

Now it executes:

1 → auth

If authentication succeeds:

next();

Express moves again:

currentIndex = 2

Now it reaches:

2 → GET /users

The route matches, so the handler executes and sends the response.

The journey looks like this:

currentIndex = 0
        │
        ▼
Logger
        │ next()
        ▼
currentIndex = 1
        │
        ▼
Auth
        │ next()
        ▼
currentIndex = 2
        │
        ▼
GET /users
        │
        ▼
Response

This also explains why the order of middleware and routes matters.

For example:

app.use(logger);

app.use(auth);

app.get("/users", getUsers);

The request always passes through:

Logger
   ↓
Auth
   ↓
Route

But if you accidentally write:

app.get("/users", getUsers);

app.use(logger);

The route handler sends the response before Express ever reaches the logger.

Route
   │
Response Sent
   │
Express Stops

The logger never runs.

That's why you'll almost always see middleware registered before routes in Express applications.

The important takeaway is this:

Express doesn't jump around your code. It simply walks through its internal stack from index 0 onward, moving one layer at a time whenever next() is called.

Following a Complete Request Journey

We've covered all the individual pieces:

• Node.js receives the request.

• Express stores middleware and routes in a stack.

• next() moves from one layer to the next.

• Express matches middleware and routes based on the path and HTTP method.

Now let's put everything together and follow a single request from start to finish.

Suppose we have the following Express application:

const express = require("express");

const app = express();

app.use(logger);

app.use(auth);

app.get("/users", getUsers);

app.listen(3000);

A client sends this request:

GET /users

Let's see what happens behind the scenes.

Step 1: Browser Sends the Request

Everything starts with the client.

Browser
   │
GET /users
   │
   ▼
Node.js HTTP Server

The browser doesn't talk directly to Express.

It sends an HTTP request to the Node.js HTTP server.

Step 2: Node.js Creates req and res

When Node.js receives the request, it creates two objects:

• req → Contains information about the incoming request.

• res → Used to send the response back to the client.

Then Node simply calls the Express application:

app(req, res);

At this moment, Express takes over.

Step 3: Express Starts Walking Through Its Stack

Internally, Express has already stored everything in the order you registered it.

1. logger
2. auth
3. GET /users

Express starts from the top.

Request
   │
   ▼
logger

Step 4: Logger Middleware Executes

function logger(req, res, next) {
    console.log(`${req.method} ${req.url}`);
    next();
}

Output:

GET /users

Then:

next();

Express moves to the next layer.

Step 5: Authentication Middleware Executes

function auth(req, res, next) {
    if (!req.headers.authorization) {
        return res.status(401).send("Unauthorized");
    }

    next();
}

Two things can happen here.

Case 1: User is not authenticated

Request
   │
Logger ✅
   │
Auth ❌
   │
401 Unauthorized

The request ends here.

The route handler is never executed.

Case 2: User is authenticated

Authentication succeeds.

next();

Express continues searching.

Step 6: Route Matching

The next layer is:

app.get("/users", getUsers);

Express checks:

• Is the request path /users?

• Is the HTTP method GET?

Both are true.

So it executes:

getUsers(req, res);

Step 7: Route Handler Executes

function getUsers(req, res) {
    res.json(users);
}

The handler performs the business logic and sends a response.

Once a response is sent, Express stops processing any more layers.

Step 8: Node.js Sends the Response

Express hands the response back to Node.js.

Node.js writes the HTTP response to the network.

Finally, the browser receives it.

Browser
   ▲
HTTP Response
   ▲
Node.js
   ▲
Express
   ▲
Route Handler
   ▲
Authentication Middleware
   ▲
Logger Middleware

The request-response cycle is complete.

The Entire Journey

Here's the complete flow in one diagram:

                 GET /users

Browser
   │
   ▼
Node.js HTTP Server
   │
Creates req & res
   │
   ▼
Express App
   │
   ▼
Logger Middleware
   │
 next()
   ▼
Authentication Middleware
   │
 next()
   ▼
Route Handler
   │
res.json(users)
   ▼
Node.js HTTP Server
   │
HTTP Response
   ▼
Browser

What I Learned

Before revising Express internals, I thought routing and middleware were handled by some kind of magic.

But after digging deeper, I realized the entire request lifecycle is surprisingly simple.

For every request:

1. Node.js receives the HTTP request.

2. Express gets req and res.

3. Express walks through its middleware and route stack.

4. Each middleware either calls next() or ends the request.

5. A matching route executes.

6. A response is sent back to the client.

That's it.

Once you understand this flow, concepts like middleware, next(), route matching, and even debugging Express applications become much easier because you can mentally trace where every request is in the pipeline.

Many developers use Node.js every day, but they don’t clearly know what happens behind the scenes when we run a simple command like:

node index.js

In this article we will understand the core internals of Node.js in a simple and beginner-friendly way.

Topics Covered

• What is Node.js

• V8 Engine and libuv

• Node.js Architecture Overview

• How Node.js Executes a Program (node index.js)

• Thread Pool in Node.js

• Event Loop and its Phases

• setTimeout vs setImmediate

• process.nextTick()

• Worker Threads

• Conclusion

What is Node.js

Originally JavaScript was designed to run inside browsers like Chrome.

JavaScript → Browser

In 2009, Ryan Dahl created Node.js by combining the V8 JavaScript engine with a library called libuv.

This allowed JavaScript to run outside the browser, especially on servers.

JavaScript → Server

Node.js is mainly built using:

V8 Engine + libuv + C++

Node.js works using a single-threaded event-driven architecture, which helps it handle many requests efficiently.

V8 Engine and libuv

V8 Engine

V8 is the JavaScript engine used in Google Chrome.

Its job is to convert JavaScript code into machine code so the computer can execute it.

Example:

console.log("Hello")

V8 compiles this code into machine instructions.

libuv

libuv is a C library that provides asynchronous capabilities to Node.js.

It manages:

• Event Loop

• Thread Pool

• File system operations

• Network requests

• Timers

The event loop and worker threads in Node.js are implemented using libuv.

Node.js Architecture Overview

The Node.js runtime consists of multiple components working together.

Main components include:

• V8 Engine → executes JavaScript

• Event Loop → manages asynchronous callbacks

• libuv Thread Pool → handles heavy tasks

• Node.js APIs → fs, http, crypto etc.

JavaScript code runs on the main thread, while heavy work can be delegated to the thread pool.

How Node.js Executes a Program

Suppose we have a file:

index.js

We run it using:

node index.js

When this command runs:

1. Node.js creates a process

2. Inside the process there is a main thread

3. JavaScript code starts executing on that thread

Top Level Code

The main thread first runs top-level code.

Top-level code means code that runs immediately when the file starts.

Example:

console.log("Hello from Top Level Code")
const fs = require("fs")

While executing this code Node.js also:

• loads modules using require()

• registers callbacks

• prepares resources for asynchronous tasks

Thread Pool in Node.js

Node.js uses a thread pool managed by libuv.

It is used for CPU intensive operations such as:

• cryptography

• hashing

• file system operations

• DNS lookups

By default the thread pool contains:

4 threads

This allows heavy tasks to run in parallel without blocking the main thread.

You can change the size using:

process.env.UV_THREADPOOL_SIZE = 10

Event Loop

After the top-level code finishes executing, Node.js starts the Event Loop.

The event loop continuously checks if there are tasks waiting to be executed.

It allows Node.js to perform non-blocking I/O operations even though JavaScript runs on a single thread.

If a task requires heavy work:

1. It is sent to the thread pool

2. The main thread continues running

3. Once the task finishes, its callback is added to the queue

Event Loop Phases

The event loop runs in phases.

Important phases include:

Timers Phase

Runs callbacks from:

setTimeout()
setInterval()

I/O Polling Phase

Handles completed I/O operations such as:

• file reading

• network requests

Check Phase

Runs callbacks scheduled using:

setImmediate()

Close Callbacks Phase

Handles events like socket closing.

Important Point: setTimeout vs setImmediate

Example:

setTimeout(() => console.log("Hello from Timer 1"), 0)

setImmediate(() => console.log("Hello from Immediate Fn 1"))

console.log("Hello from Top Level Code")

Possible output:

Hello from Top Level Code
Hello from Timer 1
Hello from Immediate Fn 1

But sometimes:

Hello from Top Level Code
Hello from Immediate Fn 1
Hello from Timer 1

This happens because the execution order between setTimeout() and setImmediate() is non-deterministic.

It depends on the performance and timing of the Node.js process, so the order may change.

process.nextTick()

Node.js also provides a special function:

process.nextTick()

This runs before the Event Loop continues to the next phase.

Example:

console.log("Start")

process.nextTick(() => {
  console.log("nextTick callback")
})

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

console.log("End")

Output:

Start
End
nextTick callback
timer callback

Execution priority:

Top Level Code
↓
process.nextTick()
↓
Event Loop

Worker Threads

Node.js also supports Worker Threads.

Worker threads allow JavaScript code to run in separate threads.

They are useful for:

• heavy computations

• data processing

• CPU intensive algorithms

Understand through visualization, I try my best to Explain this through diagram . how nodejs internals works

Conclusion

In this article we learned how Node.js works internally.

Key takeaways:

• Node.js runs JavaScript using the V8 engine

• libuv handles asynchronous operations

• The Event Loop manages callbacks

• Heavy tasks run in the thread pool

• Worker threads allow parallel processing

Understanding these concepts helps you explain Node.js internals clearly in backend interviews.