Express Middleware Explained: How the Request Pipeline Actually Works

TL;DR: Middleware in Express are functions that sit between an incoming HTTP request and the final route handler. They execute sequentially, can modify the request/response objects, and must either end the cycle or call next() to pass control forward. Understanding this pipeline is fundamental to building predictable Express applications.

Audience: This post assumes you know JavaScript and have written at least a basic Express server. No prior knowledge of middleware internals is required.

Problem

You have an Express app. Some routes need authentication. Some need request body validation. Every route should log incoming traffic. The naive approach — copy-pasting auth logic into each route handler — creates duplication, inconsistency, and maintenance nightmares.

The real problem is structural: how do you inject shared logic into the request lifecycle without polluting your route handlers?

Middleware is Express's answer.

What Middleware Actually Is

A middleware function in Express has this exact signature:

(req, res, next) => { ... }

req — the incoming HTTP request object
res — the outgoing HTTP response object
next — a function that passes control to the next middleware in the stack

Every middleware sits inside the request pipeline — a sequential chain of functions Express walks through before (and sometimes instead of) reaching your route handler.

The Pipeline Mental Model

Think of each HTTP request as a package moving down an assembly line:

HTTP Request
     │
     ▼
┌─────────────────┐
│  Middleware 1   │  (e.g., Logger)
│  logs the req   │
└────────┬────────┘
         │ next()
         ▼
┌─────────────────┐
│  Middleware 2   │  (e.g., Auth Check)
│  validates JWT  │
└────────┬────────┘
         │ next()
         ▼
┌─────────────────┐
│  Middleware 3   │  (e.g., Body Validator)
│  checks schema  │
└────────┬────────┘
         │ next()
         ▼
┌─────────────────┐
│  Route Handler  │  (your actual logic)
│  returns data   │
└─────────────────┘
         │
         ▼
   HTTP Response

If any middleware decides the request is invalid, it can short-circuit the chain by sending a response directly — without calling next(). The request stops there.

The Role of next()

next() is the gate between middleware functions. Calling it hands control to the next registered middleware. Not calling it means the request hangs — no response is ever sent.

There are three behaviors:

Action	Effect
Call `next()`	Move to the next middleware
Call `next(error)`	Skip to error-handling middleware
Call `res.send()` / `res.json()`	End the cycle, send response

// This middleware does its job and passes control forward
app.use((req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next(); // Without this, all routes below would never execute
});

Types of Middleware

1. Application-Level Middleware

Registered on the app object using app.use() or app.METHOD(). Applies to all routes or a specific path prefix.

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

// Applies to ALL incoming requests
app.use((req, res, next) => {
  req.requestTime = Date.now();
  next();
});

// Applies only to routes starting with /api
app.use('/api', (req, res, next) => {
  console.log('API route hit');
  next();
});

2. Router-Level Middleware

Works identically to application-level middleware but is bound to an instance of express.Router(). This is how you scope middleware to a specific feature module.

const express = require('express');
const router = express.Router();

// Only applies to routes in this router
router.use((req, res, next) => {
  console.log('Router-scoped middleware running');
  next();
});

router.get('/profile', (req, res) => {
  res.json({ user: 'Saurabh' });
});

module.exports = router;

Then in your main app:

const userRouter = require('./routes/user');
app.use('/users', userRouter);

3. Built-in Middleware

Express ships with a few built-in middleware functions:

// Parses incoming JSON request bodies
app.use(express.json());

// Parses URL-encoded form data
app.use(express.urlencoded({ extended: true }));

// Serves static files from a directory
app.use(express.static('public'));

Without express.json(), req.body is undefined for POST requests with a JSON payload.

Execution Order Is Deterministic

Middleware executes in registration order. This is not configurable — it's by design. Register middleware before the routes that depend on it.

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

// Step 1: Parse body first
app.use(express.json());

// Step 2: Log every request
app.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// Step 3: Route handler runs after both middleware above
app.post('/data', (req, res) => {
  res.json({ received: req.body });
});

app.listen(3000);

If you registered the route before express.json(), req.body would be undefined when the handler runs.

Real-World Examples

Example 1: Request Logger

// middleware/logger.js
const logger = (req, res, next) => {
  const start = Date.now();

  // Hook into the response finish event to log duration
  res.on('finish', () => {
    const duration = Date.now() - start;
    console.log(
      `[${new Date().toISOString()}] ${req.method} ${req.originalUrl} ${res.statusCode} — ${duration}ms`
    );
  });

  next();
};

module.exports = logger;

// app.js
const express = require('express');
const logger = require('./middleware/logger');

const app = express();
app.use(logger);

app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

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

Output on GET /health:

[2024-11-15T10:32:01.452Z] GET /health 200 — 3ms

Example 2: JWT Authentication Middleware

// middleware/authenticate.js
const jwt = require('jsonwebtoken');

const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key';

const authenticate = (req, res, next) => {
  const authHeader = req.headers['authorization'];

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing or malformed token' });
  }

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

  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    req.user = decoded; // Attach user data to request for downstream handlers
    next();
  } catch (err) {
    return res.status(403).json({ error: 'Invalid or expired token' });
  }
};

module.exports = authenticate;

// routes/profile.js
const express = require('express');
const router = express.Router();
const authenticate = require('../middleware/authenticate');

// authenticate runs before the route handler
router.get('/profile', authenticate, (req, res) => {
  res.json({ message: `Welcome, ${req.user.name}` });
});

module.exports = router;

Note how req.user set in the middleware is available in the route handler. This is the shared request context pattern — middleware attaches data, handlers consume it.

Example 3: Request Body Validation

// middleware/validateRegistration.js
const validateRegistration = (req, res, next) => {
  const { email, password, username } = req.body;

  const errors = [];

  if (!username || username.trim().length < 3) {
    errors.push('Username must be at least 3 characters');
  }

  if (!email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    errors.push('A valid email is required');
  }

  if (!password || password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }

  if (errors.length > 0) {
    return res.status(400).json({ errors });
  }

  next();
};

module.exports = validateRegistration;

// routes/auth.js
const express = require('express');
const router = express.Router();
const validateRegistration = require('../middleware/validateRegistration');

router.post('/register', validateRegistration, async (req, res) => {
  const { email, password, username } = req.body;
  // At this point, input is guaranteed to be valid
  // Proceed with user creation logic
  res.status(201).json({ message: `User ${username} created` });
});

module.exports = router;

POST /register with invalid body:

{
  "errors": [
    "Username must be at least 3 characters",
    "A valid email is required"
  ]
}

Error-Handling Middleware

Error handlers are a special class of middleware with four parameters. Express identifies them by the arity.

// Must be registered LAST, after all routes
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(err.status || 500).json({
    error: err.message || 'Internal Server Error'
  });
});

Trigger it from any middleware by calling next(new Error('Something broke')).

Results

With this middleware structure in place:

Every request is logged with method, path, status, and duration — without touching a single route handler
Unauthenticated requests to protected routes return 401/403 before any business logic runs
Invalid request bodies are rejected at the boundary — route handlers receive only validated data
Route handlers shrink to pure business logic — typically under 15 lines each

Trade-offs

Execution overhead: Every middleware runs on every matched request. A chain of 10 middleware functions adds function call overhead. In practice for most apps this is negligible (sub-millisecond), but it's worth profiling if you're seeing unexpected latency under load.

Ordering bugs are silent: If you register auth middleware after your route, Express will not warn you. The route simply executes without protection. Always register middleware before the routes that depend on it.

Global vs. scoped middleware: Applying heavy middleware globally (e.g., body parsing on static asset routes) wastes CPU. Scope middleware to the paths that need it using app.use('/api', middleware).

next() is synchronous by design: If your middleware is async, you must catch errors explicitly and pass them to next(err). Unhandled promise rejections in middleware will not trigger your error handler in Express 4.

// Correct async middleware pattern
const asyncMiddleware = async (req, res, next) => {
  try {
    const data = await someAsyncOperation();
    req.data = data;
    next();
  } catch (err) {
    next(err); // Forward to error handler
  }
};

Conclusion

Middleware is the mechanism that makes Express composable. Instead of monolithic route handlers that do everything, you build a pipeline — each function with a single responsibility, executed in a predictable sequence.

The mental model is straightforward: request comes in, walks through the chain, either gets rejected by a middleware or reaches the route handler, then a response goes out. Every complexity in production Express apps is just this pattern applied at scale.

Next step: look at how popular libraries like helmet (security headers), cors, and morgan (logging) are themselves just middleware following this exact signature — and consider extracting your existing inline logic into dedicated middleware files.

Express Middleware Explained: How the Request Pipeline Actually Works

Express Middleware Explained: How the Request Pipeline Actually Works

Problem

What Middleware Actually Is

The Pipeline Mental Model

The Role of next()

Types of Middleware

1. Application-Level Middleware

2. Router-Level Middleware

3. Built-in Middleware

Execution Order Is Deterministic

Real-World Examples

Example 1: Request Logger

Example 2: JWT Authentication Middleware

Example 3: Request Body Validation

Error-Handling Middleware

Results

Trade-offs

Conclusion

Further Reading

Comments

More from this blog

Understanding the `this` Keyword in JavaScript: What It Is and How Calling Context Controls It

Handling File Uploads in Express with Multer: A Complete Developer Guide

How React's Virtual DOM Works Under the Hood: Render, Diff, and Commit Explained

What is Node.js? JavaScript on the Server Explained

Command Palette

Express Middleware Explained: How the Request Pipeline Actually Works

Problem

What Middleware Actually Is

The Pipeline Mental Model

The Role of next()

Types of Middleware

1. Application-Level Middleware

2. Router-Level Middleware

3. Built-in Middleware

Execution Order Is Deterministic

Real-World Examples

Example 1: Request Logger

Example 2: JWT Authentication Middleware

Example 3: Request Body Validation

Error-Handling Middleware

Results

Trade-offs

Conclusion

Further Reading

Comments

More from this blog