Design Patterns in Express.js

Design Patterns in Express.js

I trashed this article due to rendering issues (sometimes, wordpress escapes html tag). Please see dzone version here

Understanding middleware pattern in express.js

Understanding middleware pattern in express.js

The term middleware (middle-ware, literally the software in the middle) may cause confusing for inexperienced and especially those coming from enterprise programming world. That is because in the enterprise architecture, middleware reminds of software suits 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, 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 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 4 arguments instead of three allowing expressjs to recognize this middleware as error-handling

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

Middleware functions can perform 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:

alt text

  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 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

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