Concise async / await in ExpressJS

Async / await is one of the biggest revolutions (read: one of the sweetest syntactical sugars) that has come to JavaScript over the past few months, and has personally helped me appreciate the language a lot more.

At work, we rely quite a lot on ExpressJS to build small services deployed in our architecture and, as you can imagine, have converted a whole bunch of them to async / await over time.

One interesting problem, though, has been converting express routes to use async functions: my personal solution has been to write express-async-await, and I want to share the reasons and ideas behind the library in this post.

A typical express scenario

Before we understand the problem, I want to clarify the scenario we’re looking at — a simple app with a few routes and an error handler to catch’em all:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
app.get('/users', function(req, res, next){
  db.getUsers().then(function(users) => {
    res.json(users)
  }).catch(next)
})

app.get('/users/:id', function(req, res, next){
  db.getUser(req.params.id).then(function(users) => {
    res.json(users)
  }).catch(next)
})

app.use(function(err, req, res, next) {
  console.error(err)
  res.status(500).json({message: 'an error occurred'})
})

As you see, we simply have a couple routes which use some promise-based service (we could even use callbacks, I’m using promises here just for the sake…) and an error handler that intercepts any error and returns a “standard” response should anything fail in the routes.

Can we do better?

The problem with async functions

Lauded for its simplicity and readability, async / await can help us make the code a bit more elegant:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
app.get('/users', async function(req, res, next){
  try {
    res.json(await db.getUsers())
  } catch(err) {
    next(err)
  }
})

app.get('/users/:id', async function(req, res, next){
  try {
    res.json(await db.getUser(req.params.id))
  } catch(err) {
    next(err)
  }
})

app.use(function(err, req, res, next) {
  console.error(err)
  res.status(500).json({message: 'an error occurred'})
})

Now, you probably see where I’m headed: each and every route we add needs to have some boilerplate to catch errors and forward them to the error handler, and that’s where my OCD kicked in — there needs to be a better way of doing this.

Solution 1: the wrapper

Turns out that the solution is quite simple, you can just create a wrapper that catches the error and calls next:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
const asyncMiddleware = fn =>
  (req, res, next) => {
    Promise.resolve(fn(req, res, next))
      .catch(next);
  };

app.get('/users', asyncMiddleware(async function(req, res, next){
  res.json(await db.getUsers())
}))

app.get('/users/:id', asyncMiddleware(async function(req, res, next){
  res.json(await db.getUser(req.params.id))
}))

app.use(function(err, req, res, next) {
  console.error(err)
  res.status(500).json({message: 'an error occurred'})
})

Much better, right? Well, at least I think so: now our routes are one-liners that defer to a service and error handling is out of the picture, as it’s taken care by the asyncMiddleware function (here’s a good article on the topic).

The biggest drawback, in my opinion, is that the routes are now looking less “pure” than they should: they’re all wrapped in this asyncMiddleware which looks kind of awkward. What if we were able to “hide” this implementation detail from our code?

Solution 2: express-async-await

That’s where express-async-await kicks in: it’s a tiny library I wrote to be able to monkey-patch your express app so that you don’t need to wrap each and every route:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
require('express-async-await')(app)

app.get('/users', async function(req, res, next){
  res.json(await db.getUsers())
})

app.get('/users/:id', async function(req, res, next){
  res.json(await db.getUser(req.params.id))
})

app.use(function(err, req, res, next) {
  console.error(err)
  res.status(500).json({message: 'an error occurred'})
})

…and that’s it! The library takes care of monkey-patching express’ HTTP methods (like app.get, app.post, etc) and automatically wrap them with the asyncMiddleware we’ve seen earlier on.

Biggest drawback? Well, some are really against monkey-patching (for good reasons) but, when used with caution, I think it can be a really effective way to enhance a library that’s missing an interesting feature1.

Notes
  1. By the way, my bet is that within a year express is going to support this “natively”

Hi there! I recently wrote an ebook on web application security, currently sold on leanpub, the Amazon Kindle store and gumroad.

It contains 160+ pages of content dedicated to securing web applications and improving your security awareness when building web apps, with chapters ranging from explaining how to secure HTTP cookies with the right flags to understanding why it is important to consider joining a bug bounty program.

Feel free to skim through some of the free chapters published on this blog and, if the content seems interesting enough to you, grab a copy on leanpub, the Amazon Kindle store, gumroad or simply checkout right down below!

Buy the Web Application Security ebook for $9.99

In the mood for some more reading?

...or check the archives.