Middleware accomplish two things:

Define global behavior for routes
Make asynchronous code easier to write

Both are problematic. To elaborate on the first, consider a typical express application:

app.use(logger());
app.use(needsAuth());
app.get('/my-route', require('./my-route'));

Then, imagine you want to add a route /log for which you want to turn off request logging and authentication. You end up with awkward code that introduces a global whitelist of exceptions.

app.use(function(req, res, next){
  if ('/log' === req.url) return next();
  logger(req, res, next);
});

Assuming that through experience and discipline you avoid this pitfall, you probably then rely on defining middleware for each route through "sub-apps".

// boot.js
app.use(require('./my-route');

// my-route.js
const bodyParser = require('body-parser');
module.exports = express().get('/', bodyParser, function(req, res, next){
  // req.body
});

This pattern, however, still has significant problems:

req.body comes out of nowhere. It's unclear to someone who's never seen the codebase before that the presence of bodyParser is what made req.body exist.
Error handling is done by the framework in a similarly obscure way (app.error).
It's not clear whether bodyParser will hold up the request or not.

await + async is the solution to all of these problems.

First, the assignment operator brings clarity:

async function (req, res) {
  const body = await json(req); // explicit
}

function (req, res, next) {
  req.body                      // where did this come from? (╯°□°）╯︵ ┻━┻
}

Second, errors are handled like everywhere else:

async function (req, res) {
  try {
    await json(req);
  } catch (e) {
    // buffering failed
    // size limit exceeded
    // parsing failed
  }
}

If you don't specify try/catch and instead the error is caught by micro, it goes with a suggested code (err.statusCode), or 500 if no information can be derived from the Error.

This flexibility in error handling is very difficult to achieve with middleware. In general, middleware skip over subsequent routes and go to the error handler (also not very obvious).

Third, the presence of the await keyword will tell you if the request is actually being defered or not.

async function (req, res) {
  await rateLimit(req);    // this holds up the request
  log(body);               // this doesn't hold up the request
  send(res, 200, 'woot!'); // no `res` monkey-patching
}

Finally, you might still favor global middleware to avoid incessant repetition. You could successfully argue that if every route in your app requires logging, this pattern falls into "pre-mature optimization".

Fortunately for us, simple functions solve this without sacrificing explicitness:

import decorate from './my-middleware';
export default decorate(async (req, res) => {
  // the introduction of re-usable logic is explicit and 
  // the programmer knows to look at `my-middleware.js`
});

As you can see, micro goes beyond "syntax sugar" or "making async code look sync". It's about code that's easier to understand, debug and collaborate on.

Explicit. No middleware ? #8

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions