Hello readers 👋, welcome to the 10th blog in our Node.js series!

In the last post, we built a clean REST API using Express.js for a users resource. We defined routes and handled different HTTP methods. Today, we are going to explore a concept that sits quietly at the heart of every Express application: middleware.

If you have ever wanted to log every request, check authentication tokens, or validate incoming data before it hits your route handler, you have needed middleware. Let's understand what middleware is, how it fits into the request lifecycle, the different types, and how to chain multiple middleware to build powerful, reusable pipelines.

Let's get started.

What middleware is in Express

Middleware, in Express, are functions that have access to the request object (req), the response object (res), and the next middleware function in the application's request-response cycle. The next middleware function is conventionally denoted by a variable named next.

Think of middleware as a series of checkpoints or processing stations that every incoming request passes through before reaching the final route handler. At each checkpoint, you can:

• Inspect or modify the request (e.g., add properties, parse the body).
• Perform some logic (e.g., log the request time, check authentication).
• Send an early response (e.g., return an error if the user is not authenticated) and stop the chain.
• Call next() to pass control to the next middleware in line.

Middleware functions are executed in the order they are defined. That order is crucial and we'll explore it soon.

Where middleware sits in the request lifecycle

In a typical Express app, an incoming HTTP request flows through a pipeline:

1. The request arrives at the server.
2. It passes through each middleware function registered (both application-level and router-level) in the order they were added.
3. Finally, it reaches the route handler that matches the path and method.
4. The route handler sends a response.
5. If no middleware or route sends a response, the request hangs; Express doesn't automatically respond.

The middleware chain can be visualized as:

Request → [Middleware 1] → [Middleware 2] → [Route Handler] → Response

Each arrow is a next() call. If a middleware function does not call next(), the request stalls and never reaches the next middleware or route handler (unless you send a response and end the request). This pipeline concept is the backbone of Express.

The role of next()

The next function is a callback that tells Express "I'm done, move on to the next middleware or route handler." If the currently executing middleware function does not end the request-response cycle, it must call next().

There are two important variations:

• next() – proceed to the next middleware in the stack.
• next('route') – skip to the next route handler (only works in router-level middleware).

If you pass an error to next(err), Express skips all remaining non-error middleware and goes directly to an error-handling middleware, which has four parameters: (err, req, res, next). We'll keep error handling middleware for another post.

Application-level middleware

Application-level middleware are bound to an instance of the app object using app.use() or app.METHOD(). They run for every request (if no path is specified) or for requests that match a specific path prefix.

Example: logging middleware for every request

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

// Application-level middleware (no path, runs on every request)
app.use((req, res, next) => {
  console.log(`${req.method} ${req.url} - ${new Date().toISOString()}`);
  next();
});

Here, we log the HTTP method, URL, and timestamp for every request. We then call next() so the request continues down the pipeline.

Example: middleware for a specific path

You can limit middleware to a path prefix:

app.use('/admin', (req, res, next) => {
  console.log('Admin route accessed');
  next();
});

Middleware added this way will run for any route starting with /admin.

Router-level middleware

Router-level middleware works exactly like application-level middleware, except it is bound to an instance of express.Router(). It's used to organize route-specific middleware, especially when you have modular route files.

const router = express.Router();

// Router-level middleware: runs for every request handled by this router
router.use((req, res, next) => {
  console.log('Inside user router');
  next();
});

router.get('/profile', (req, res) => {
  res.send('User profile');
});

app.use('/users', router);

Now, any request starting with /users will first go through the router-level middleware before hitting the specific route handler.

Built-in middleware

Express has some built-in middleware functions that solve common tasks. You've already seen one: express.json(). These are middleware functions that come with Express and are used via app.use().

• express.json() – parses incoming JSON payloads and populates req.body.
• express.urlencoded({ extended: true }) – parses URL-encoded payloads (from HTML forms).
• express.static('public') – serves static files (images, CSS, JS) from a directory.

Example:

app.use(express.json());
app.use(express.static('public'));

These are middleware too! They process the request and call next() for the next piece in the pipeline.

Execution order of middleware

The order in which you declare middleware matters immensely. Express executes them sequentially, top to bottom. If you place a middleware that sends a response before your route handler, the route handler will never run.

Consider this incorrect example:

app.use((req, res, next) => {
  res.send('This ends the request');
  next(); // This will still be called but no further middleware can modify the response after send
});
app.get('/', (req, res) => {
  res.send('Hello world');
});

Here, the first middleware sends a response, and unless you call next() before send(), the get handler never sees the request. More importantly, even if you call next() after send(), Express will not allow you to send another response; you'd get an error because headers are already sent. So, typically you either call next() without sending a response, or you end the request inside the middleware.

The correct pattern:

app.use((req, res, next) => {
  console.log('Logging');
  next(); // pass control
});

app.use((req, res, next) => {
  // maybe add timestamp to req
  req.requestTime = Date.now();
  next();
});

app.get('/', (req, res) => {
  res.send(`Hello world, request at ${req.requestTime}`);
});

Each middleware adds something and passes control. The route handler runs at the end.

Real-world examples

Let's see three practical middleware: logging, authentication, and request validation.

Logging middleware

You've already seen a basic logger. Let's write a slightly cleaner one:

function logger(req, res, next) {
  const start = Date.now();
  res.on('finish', () => {
    const duration = Date.now() - start;
    console.log(`${req.method} ${req.originalUrl} ${res.statusCode} - ${duration}ms`);
  });
  next();
}
app.use(logger);

This logs the method, URL, status code, and response time. It uses the finish event on the response to know when the response is sent.

Authentication middleware

This one checks for a valid JWT token (similar to our earlier JWT blog). If invalid, it stops the request with a 401 error. Otherwise, it attaches the user and continues.

function authenticate(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];
  if (!token) {
    return res.status(401).json({ message: 'Access token missing' });
  }
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (err) {
    return res.status(403).json({ message: 'Invalid token' });
  }
}
// Protect a route
app.get('/profile', authenticate, (req, res) => {
  res.send(`User profile for ${req.user.userId}`);
});

Notice how the middleware stops the request (by returning a response) when authentication fails, so the route handler never executes.

Request validation middleware

You can validate input before it reaches business logic. This keeps your route handlers clean. Here's a simple one for creating a user:

function validateUserInput(req, res, next) {
  const { name, email } = req.body;
  if (!name || !email) {
    return res.status(400).json({ message: 'Name and email are required' });
  }
  if (typeof email !== 'string' || !email.includes('@')) {
    return res.status(400).json({ message: 'Invalid email' });
  }
  next();
}

app.post('/users', validateUserInput, (req, res) => {
  // create user logic...
});

When validation fails, we respond immediately with 400 Bad Request. Otherwise, next() passes control to the actual handler. This separation improves readability and reusability.

Middleware pipeline

Imagine a physical pipeline with several inspection stations. A request arrives, gets stamped at the logging station, then passes through a security gate (authentication), then a quality check (validation), and finally reaches the desired destination (route handler). At any point, if it fails inspection, it gets turned away with a response.

Conclusion

Middleware is one of those concepts that, once you understand it, Express becomes transparent. It's just a sequence of functions that have access to req and res and can either pass the request along with next() or end the cycle by sending a response. By chaining middleware, you can separate concerns like logging, authentication, and validation, making your code cleaner and more maintainable.

Let's quickly recap:

• Middleware functions sit between the incoming request and the final route handler.
• They can modify the request/response, run code, or end the request early.
• The next() function passes control to the next middleware in the stack; without it, the request stalls.
• Application-level middleware (app.use()) runs for all requests or a specific path.
• Router-level middleware (router.use()) works for a specific router.
• Built-in middleware like express.json() are just prepackaged middleware.
• Execution order is top-to-bottom, so declare middleware before routes they should affect.
• Real-world uses include logging, authentication, and input validation, which keep route handlers focused.

Now that you understand middleware, you can structure Express apps that are modular, secure, and easy to scale. In the next post, we'll continue building more practical features. See you there!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.