Middleware NodeJs

Understanding Middleware Types and Invocation Order in Express Applications

admin Apr 2, 2024

When building web applications with Express, middleware forms the backbone of request processing, offering a versatile way to handle HTTP requests. In this post we are goingt to review the different types of middleware available in Express and their invocation order. Whether, you're implementing authentication, parsing request bodies, handling CORS, or managing errors, understanding middleware is crucial.

What is ExpressJS Middleware?

Middleware in Express is a function that has access to the request object (req), the response object (res), and the next middleware in the application’s request-response cycle. These functions can execute code, make changes to the request and response objects, terminate the request-response cycle, and call the next middleware in the stack.

Middleware implementation

Implementing middleware in an Express application involves creating a function that has access to the request object (req), the response object (res), and the next middleware function in the application's request-response cycle, commonly referred to as next:

function myLogger(req, res, next) {
  console.log('LOGGED');
  next(); // Call next() to pass control to the next middleware function in the stack.
}

The next function is crucial; calling it passes control to the next middleware function in the stack. If next() is not called, the request will be left hanging, and the client will not receive a response.

Middleware registration

You can apply the middleware globally to all requests or locally to specific routes.

app.use(myLogger);

app.get('/about', myLogger, (req, res) => {
  res.send('About Page');
});

Chain of Responsibility Design Pattern

The Express Middleware is an implementation of the Chain of Responsibility design pattern. This pattern allows an object (in this case, a request) to pass through a chain of handlers (middleware functions) in sequence until one of them handles the object fully. Each handler in the chain has the chance to process the request, perform actions such as logging, request modification, validation, or even terminating the request by sending a response. If it doesn't finalize the request, it can pass the request along to the next handler in the chain by calling a next() function.

The Chain of Responsibility pattern is particularly powerful in web application development for several reasons:

Decoupling: It decouples the sender of a request from its receivers by giving multiple objects a chance to handle the request. This separation of concerns makes the application easier to maintain and extend.
Flexibility in Assigning Responsibilities: It provides more flexibility in assigning responsibilities to objects. Middleware can be easily added or removed from the chain without affecting other middleware.
Dynamic Configuration: The chain can be dynamically configured at runtime, allowing for flexible control over which middleware are active based on the application's state or configuration settings.

In the context of an Express application, middleware functions handle HTTP requests, perform specific tasks (e.g., authentication, data parsing, logging), and then either conclude the request-response cycle or pass control to the next middleware in the chain. This aligns perfectly with the principles of the Chain of Responsibility pattern, offering a structured yet flexible approach to request handling.

Types of Middleware in Express

Application-level Middleware

Applied globally to all incoming requests, application-level middleware handles tasks such as logging, body parsing, and global authentication. They are registered using app.use() and app.METHOD(), where METHOD is an HTTP method.

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

// Application-level middleware for logging
app.use((req, res, next) => {
  console.log(`${new Date().toISOString()} - ${req.method} ${req.path}`);
  next();
});

Router-level Middleware

Offering a more granular level of control, router-level middleware is scoped to specific routes or route groups, facilitating the segmentation of your application.

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

// Router-level middleware for authentication
router.use((req, res, next) => {
  if (req.query.authToken) {
    next();
  } else {
    res.status(403).send('Authentication required');
  }
});

router.get('/protected', (req, res) => {
  res.send('Access granted to protected route');
});

app.use(router);

Route Path Middleware

Unlike the router-level middleware which applies to the entire router, Route-Path middleware are specifically targeting route paths, being applied to routes matching a certain pattern or path, allowing for path-specific logic before reaching the route handler.

// Route path middleware for specific path
app.use('/special', (req, res, next) => {
  console.log('Accessing the special section');
  next();
});

app.get('/special/offer', (req, res) => {
  res.send('Welcome to the special offer page');
});

Error-handling Middleware

Express distinguishes error-handling middleware with its signature, which includes an error parameter, allowing centralized error management.

// Error-handling middleware
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Internal Server Error');
});

Built-in Middleware

Express includes built-in middleware for serving static files and parsing request bodies, enhancing its utility straight out of the box.

// Serving static files
app.use(express.static('public'));

// Parsing JSON bodies
app.use(express.json());

Third-party Middleware

To extend Express's capabilities, third-party middleware can be incorporated, such as cors for CORS handling or morgan for request logging.

const cors = require('cors');
app.use(cors());

const morgan = require('morgan');
app.use(morgan('tiny'));

Each type of middleware in Express serves a unique purpose, from handling all requests at the application level to applying specific logic to certain routes or even managing errors. By combining these middleware types strategically, you can create robust, flexible, and maintainable web applications with Express.

Invocation order

The invocation order of middleware is crucial and is explicitly controlled by their registration order within the application. The sequence in which middleware is added determines its execution order, adhering to the following principles:

Sequential Use: Middleware functions are invoked in the sequence they are registered, from top to bottom as they appear in the application code.
Router and Route-Specific Middleware: Within a router, middleware is executed in the order it's defined. Router-level middleware precedes any route-specific middleware for routes within that router.
Error Handling at the End: Error-handling middleware is generally registered last to capture any errors from preceding middleware and routes.

The relationship between application-level and router-level middleware showcases the importance of registration order. If application-level middleware is registered before a router, it will be invoked for every request before any router-level middleware. However, if a router is mounted before application-level middleware, the middleware within that router (including route-specific middleware) will execute before the application-level middleware for requests matching the router's routes.

Application-Level, Router-Level, and Route-Specific Middleware Example

The following Express application example is designed to demonstrate the invocation order of different types of middleware: application-level, router-level, and route-specific middleware. This setup ensures that the order of middleware execution is clear, showcasing how middleware added at various levels interacts within an Express application.

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

// First application-level middleware
app.use((req, res, next) => {
  console.log('First application-level middleware executed');
  next();
});

// Router instance
const router = express.Router();

// Router-level middleware
router.use((req, res, next) => {
  console.log('Router-level middleware executed');
  next();
});

// Route-specific middleware
const routeSpecificMiddleware = (req, res, next) => {
  console.log('Route-specific middleware executed');
  next();
};

// Route within the router using route-specific middleware
router.get('/example', routeSpecificMiddleware, (req, res) => {
  console.log('Response from /example route');
  res.send('Response from /example route');
});

// Mount the router between two application-level middlewares
app.use('/router', router);

// Second application-level middleware
app.use((req, res, next) => {
  console.log('Second application-level middleware executed');
  next();
});

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

This code structure deliberately illustrates the layered approach to middleware in Express, emphasizing the order of invocation based on the middleware's registration order in the application. Requests to /router/example will traverse the middleware stack in the sequence outlined, providing a clear demonstration of middleware execution order in Express applications:

First Application-level Middleware: This middleware is registered first and will execute for all incoming requests to the application, regardless of the route.
Router-level Middleware: Registered within the router, this middleware executes for any request that matches a route defined within this router instance.
Route-specific Middleware: Applied directly to a specific route (/example) within the router. It executes after the router-level middleware but before the route handler for requests to /router/example.
Mounting the Router: The router is mounted to the application on the /router path. At this point, any request to paths beginning with /router will first pass through the first application-level middleware, then proceed through the router-level middleware, and finally to any route-specific middleware or handlers defined within the router.
Second Application-level Middleware: Registered after the router, this middleware would typically execute for requests not fully handled by preceding middleware or routes. However, in this specific setup, because the router's route handler for /example sends a response, requests to /router/example will complete their cycle before reaching this middleware. This middleware will execute for other paths not matched by the router.

Middleware Example: Error-handling, Built-in Middleware and Third-party Middleware

To extend the previous example and include error-handing middleware, built-in middleware, and an example of third-party middleware, let's enhance the Express application. This version incorporates express.json() as built-in middleware for parsing JSON request bodies, a simple error-handling middleware, and a hypothetical third-party middleware for CORS handling. Note that for third-party middleware like CORS, you'd typically use a package such as cors, which can be installed via npm. However, for the sake of this example, I'll define a simple custom middleware to simulate CORS handling.

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

// Built-in Middleware for parsing JSON bodies
app.use(express.json());

// Third-party Middleware for CORS (Cross-Origin Resource Sharing)
// In a real-world scenario, you would use: const cors = require('cors'); app.use(cors());
app.use((req, res, next) => {
  console.log('Third-party CORS middleware executed');
  res.setHeader('Access-Control-Allow-Origin', '*');
  next();
});

// First application-level middleware
app.use((req, res, next) => {
  console.log('First application-level middleware executed');
  next();
});

// Router instance
const router = express.Router();

// Router-level middleware
router.use((req, res, next) => {
  console.log('Router-level middleware executed');
  next();
});

// Route-specific middleware
const routeSpecificMiddleware = (req, res, next) => {
  console.log('Route-specific middleware executed');
  next();
};

// Route within the router using route-specific middleware
router.get('/example', routeSpecificMiddleware, (req, res) => {
  console.log('Response from /example route');
  res.send('Response from /example route');
});

// Mount the router between two application-level middlewares
app.use('/router', router);

// Second application-level middleware
app.use((req, res, next) => {
  console.log('Second application-level middleware executed');
  next();
});

// Error-handling Middleware
app.use((err, req, res, next) => {
  console.error('Error-handling middleware executed:', err);
  res.status(500).send('An error occurred!');
});

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

This enhanced example provides a comprehensive overview of different types of middleware in Express, showcasing their order of execution and how they contribute to the structure and functionality of an Express application.

Built-in Middleware (express.json()): This middleware is used to automatically parse JSON formatted request bodies, making them easily accessible via req.body. It's one of Express's built-in functionalities, enhancing the framework's utility.
Third-party Middleware (CORS): For illustrative purposes, a custom middleware simulating CORS handling is added. In a real application, you would likely use the cors npm package, which simplifies setting appropriate CORS headers. This middleware sets the Access-Control-Allow-Origin header to *, allowing all domains to access resources from the server.
Error-handling Middleware: Placed at the end of all middleware and route definitions, this middleware is designed to catch any errors that occur during the processing of requests. Its signature includes an err parameter, distinguishing it from other middleware types. This centralized error handling ensures that any unhandled errors are processed in a uniform manner.
Router and Route-specific Middleware: As before, router-level and route-specific middleware demonstrate scoped middleware functionality within a router instance, affecting only the routes defined within.

Error-handling middleware

Defined last, with a signature of (err, req, res, next). It catches and processes any errors that occur during the processing of requests. The error-handing middleware will only be invoked when an error is passed to the next() function from any of the preceding middleware or route handlers. If no errors occur, the error-handling middleware will not be executed.

// Application-level and other middleware
app.use(someMiddleware);

// Routes
app.get('/some-route', (req, res, next) => {
  // Some logic that might call next(err) if an error occurs
});

// Error-handling middleware placed at the end
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

In this flow, if any middleware or route handler before the error-handling middleware calls next() with an error object (i.e., next(err)), Express will skip all remaining non-error-handling middleware and route handlers, moving directly to the error-handling middleware. This design ensures that errors are managed in a centralized and consistent manner, provided the error-handling middleware is correctly positioned at the end of the middleware stack.

CORS Middleware Example

For CORS (Cross-Origin Resource Sharing) middleware, its placement within your Express application generally depends on your specific needs and security considerations, but it's often added near the beginning of your middleware stack. This early placement ensures that CORS headers are added to responses before any potential error conditions are encountered and handled by subsequent middleware or route handlers. By doing so, it allows for the preflight requests (HTTP OPTIONS method) to be handled properly and ensures that CORS policies are consistently applied across all routes.

Here's why positioning CORS middleware early is beneficial:

Preflight Requests: Browsers send preflight requests to determine whether they have permission to perform an action according to CORS policy. Adding CORS middleware at the beginning ensures these preflight requests are immediately responded to with the correct headers.
Security: Early CORS middleware application can help define a clear security boundary. By setting CORS headers early, you ensure all responses, including errors thrown by subsequent middleware or routes, adhere to your CORS policy.
Simplicity and Consistency: Placing CORS middleware early in your stack simplifies debugging and ensures consistent application of your CORS policy across all your routes and middleware.

const express = require('express');
const cors = require('cors'); // Assuming cors is installed via npm

const app = express();

// CORS middleware added near the beginning
app.use(cors());

// Other middleware
app.use(express.json()); // Built-in middleware for JSON body parsing

// Routes
app.get('/some-route', (req, res) => {
  res.json({ message: 'This route is CORS-enabled for all origins!' });
});

// Error-handling middleware at the end
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

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

In this configuration, CORS headers are applied to all responses from /some-route, including any error responses generated by the error-handling middleware or other middleware that may produce errors. This ensures that your application's CORS policy is uniformly applied, enhancing both functionality and security.

Middleware NodeJs