Understanding the Middleware Pattern in Express.js

The term middleware (middle-ware, literally the software in the middle) may cause confusion for the inexperienced and especially those coming from the enterprise programming world. This is because, in enterprise architecture, middleware reminds of software suites that shield developers from having to deal with many of the low-level and difficult issues, allowing developers to concentrate on business logic.

In express.js, a middleware function is defined as:

Middleware functions 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 commonly denoted by a variable named next.

A middleware function has the following signature:

function(req, res, next) { ... }

There is a special kind of middleware named error-handling. This kind of middleware is special because it takes four arguments instead of three allowing Express to recognize this middleware as error-handling:

function(err, req, res, next) {...}

Middleware functions can perform the following tasks:

• Logging requests
• Authenticating/authorizing requests
• Parsing the body of requests
• End a request – response lifecycle
• Call the next middleware function in the stack.

These tasks are not core concerns (business logic) of an application. Instead, they are cross cutting concerns applicable throughout the application and affecting the entire application.

Request-response lifecycle through a middleware is as follows:

1. The first middleware function (A) in the pipeline will be invoked to process the request
2. Each middleware function may end the request by sending response to client or invoke the next middleware function (B) by calling next() or hand over the request to an error-handling middleware by calling next(err) with an error argument
3. Each middleware function receives input as the result of previous middleware function
4. If the request reaches the last middleware in the pipeline, we can assume a 404 error

app.use((req, res) => {
    res.writeHead(404, { 'Content-Type': 'text/html' });
    res.end("Cannot " + req.method.toUpperCase() + " " + req.url);
});

As we can see, the idea behind the middleware pattern is not new. We can consider middleware pattern in Express.js a variant of:

• Intercepting Filter
• Chain of Responsibility

This pattern has some benefits:

• Avoid coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Both the receiver and the sender have no explicit knowledge of each other.
• Flexibility in distributing responsibilities among objects. We add or change responsibilities for handling a request by adding to or changing the chain at run-time.

References

• http://www.oracle.com/technetwork/java/interceptingfilter-142169.html
• http://www.javaworld.com/article/2073684/java-web-development/follow-the-chain-of-responsibility.html
• http://expressjs.com/en/guide/using-middleware.html

Update: A new post about design patterns in Express has been published. If you want to take a look, please follows this link