DEV Community

Cover image for The dangers of async/await
Christopher Kade
Christopher Kade

Posted on • Originally published at christopherkade.com

The dangers of async/await

After a few months consulting on the rewriting of a large-scale application, I've come to realize that async/await was used de facto for most asynchronous operation and parallel executions seemed to be out of the picture. For example, consider this Vue code snippet:

 async initStore(query) {
    await this.getConfig();
    await this.getUser();
    await this.checkRussianContext(query);

    await this.getBasket(this.$store.state.config.selectedCurrency),

    await this.$store.dispatch('options/fetchOptions', {
      basket : this.$store.state.basket,
    });
 },
Enter fullscreen mode Exit fullscreen mode

Here, each line of code is executed when its predecessor is completed. Meaning getUser will wait for getConfig to finish fetching data before being executed.

Here are a few points that come to mind when seeing this snippet:

  • What if one line does not need data from the previous one? Why block its execution and slow down our application?
  • Could we run unrelated methods in parallel using something like Promise.all?
  • Related methods should probably be using a then block to avoid blocking the rest of the method

The point this article will be to help you catch this code smell by showing you that using async/await by default in some cases can have a drastic impact on performance and UX.

Unrelated queries should be executed in parallel

Let's see some concrete data, shall we?

Here's the code snippet we'll be analyzing:

const getUserData = async () => {
  // Get a random dog as our user's avatar
  const res = await fetch('https://dog.ceo/api/breeds/image/random')
  const { message } = await res.json()

  // Get our user's general data
  const user = await fetch('https://randomuser.me/api/')
  const { results } = await user.json()

  // ...
}
Enter fullscreen mode Exit fullscreen mode

Running this snippet 100 times on fast 3G (using Chrome's dev tools), the average execution time is 1231.10ms.

But why block the second query when it doesn't need the result of the first? Let's change our code to the following and re-run it 100 times.

const getUserDataFaster = async () => {
  // Execute both requests in parallel
  const [res, user] = await Promise.all([
    fetch('https://dog.ceo/api/breeds/image/random'), 
    fetch('https://randomuser.me/api/')
  ])
  const [{ message }, { results }] = await Promise.all([res.json(), user.json()])

  // ...
}
Enter fullscreen mode Exit fullscreen mode

We now have an average execution time of 612.50ms, half the time needed when both queries were executed one after the other.

The point is: if you can execute time-consuming queries in parallel, do it.

Try it out yourself on this codepen.

Unrelated code should not have to wait

Let's take my first example but with a twist:

 async initStore(query) {
   await Promise.all([
     this.getConfig(),
     this.getUser(),
     this.checkRussianContext(query)
   ])

   await this.getBasket(this.$store.state.config.selectedCurrency),

   await this.$store.dispatch('options/fetchOptions', {
     basket : this.$store.state.basket,
   });

   await initBooking()
 },
Enter fullscreen mode Exit fullscreen mode

Here, the first 3 requests are executed in parallel, whereas the next ones rely on data fetched beforehand and will therefore be executed afterwards. Although this snippet poses a problem, did you spot it?

Poor little initBooking will have to wait for both getBasket and fetchOptions to finish before executing even though it has nothing to do with the data they'll fetch.

An easy solution is to trade the await with a simple then block.

  async initStore(query) {
    await Promise.all([
      this.getConfig(),
      this.getUser(),
      this.checkRussianContext(query)
    ])

    this.getBasket(this.$store.state.config.selectedCurrency).then(async () => {
      await this.$store.dispatch('options/fetchOptions', {
        basket : this.$store.state.basket,
      });
    })   

   await initBooking()
 },
Enter fullscreen mode Exit fullscreen mode

This way, both getBasket and initBooking will be executed alongside one another.

Want to see it for yourself? Check out this codepen illustrating my example.

I'll stop the article there so I don't overload you with examples, but you should get the gist of it by now.

async/await are wonderful additions to the Javascript language but I hope you'll now ask yourself if they have their place in the specific method you're working on and more importantly: if some of your queries could be executed in parallel.

Thank you for reading, I'd love it if you gave me a follow on Twitter @christo_kade, this way we'll get to share our mutual skepticism towards awaits ❀️

Top comments (39)

Collapse
 
lucis profile image
Lucis

async/await are (almost) syntatic sugar for the plain-old Promise API, you could accomplish the same "blocking" behaviour using promise1().then(promise2).then(promise3) and so on, thus this is not a problem with async/await syntax per-se, IMO.

One using await should first know about the Promise API, so it'll know better how to use it

Collapse
 
christopherkade profile image
Christopher Kade

Absolutely, and even when knowing these tools some developers tend not to prioritize parallel executions for some reason. A colleague said the same thing as you after reading it, and it's very pertinent.

Thanks Luciano !

Collapse
 
lucis profile image
Lucis

I would suggest you to write a post of "How to parallelize your work with async/await". There's a nice feature that is something like:

const p1 = promise1()
const p2 = promise2()
const r1 = await p1
const r2 = await p2

If I'm not mistaken, this way you 1) use async/await, what's really nice 2) let the promises run right-away

Thread Thread
 
acce profile image
Lawrence tranter

Promise chains are a problematic solution, as each '.then' produces another promise. What happens if an earlier 'then' throws and there's no catch or other error handling? Memory leak

Thread Thread
 
acce profile image
Lawrence tranter

Welp. JS got us on this one. The new using keyword allows for simpler handling of cleanup if there was an error that would cause memory leaks otherwise.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

well the trade-off here is that by using parallelism, you will probably spend more time coding and debugging your code.
I think it's fine to do the simple thing by default and parallelize only when you have measured that it's worth it

Collapse
 
christopherkade profile image
Christopher Kade

Agreed, to some extent. If you have a clear way of determining which query failed and why, it shouldn't be taking you more time to debug whenever one of them throws an error.

As you said, it must be a calculated risk.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

It depends, if you have two http queries that are totally independant OK, but if you have a number of asynchronous calls that do side effects, it's much harder to reason about it if you add parallelism

Thread Thread
 
christopherkade profile image
Christopher Kade

That's a good point yeah, it can make it much harder to determine the cause of everything falling apart. It really should be done in the right circumstances.

Thread Thread
 
mx profile image
Maxime Moreau

Async with side effects is my nightmare :(

Collapse
 
matthisd profile image
Matthis Duclos

I think your article points out the fact we need to parallelize calls that don't depend on each other. I already read some code using promises that could have been parallelized too.

One of the advantages about async/await (outside the fact that the code may be easier to read) is that it can improve stacktraces. To know more about this point, I encourage you to read this blog post from Mathias Bynens

Collapse
 
integerman profile image
Matt Eland

This is kind of funny. I was planning on writing an article this evening with something pretty close to this title, but focused on C# code.

Different points, but... still, I'll have to rethink that or at least the title.

Collapse
 
christopherkade profile image
Christopher Kade

I'd love to read your take on it either way :) sorry for beating you to it haha

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

The title is just a bit misleading, it's more a discussion about parellelism vs serial execution.
I agree, if you don't take the program flow into account you can horribly increase application latency.
Good post

Collapse
 
khrome83 profile image
Zane Milakovic

What a great write up. This is super valid code smell. I forget about this a lot when I am writing code with asynchronous/await first pass.

But when I do promises, I typically don’t. I never tried the promise with async/await like that. It’s clever and I am going to use it. Well done!

Collapse
 
christopherkade profile image
Christopher Kade

Absolutely, thanks for catching my mistake. Must have made it while pasting my notes !

Collapse
 
nudelx profile image
Alex Nudelman

Absolutely! But there is a problem. If one of those will fail it will break all promise.all() iteration and you will be thrown into the catch. So I if you need/want to run fully async and parallel and get all results (errors and values) regardless of the failures you should use this:

 const promiseAllWithAllErrors = function(mapAsync) {
  return Promise.all(
    mapAsync.map(f =>
      f.then(r => Promise.resolve(r)).catch(e => Promise.resolve(new Error(e)))
    )
  )
}


promiseAllWithAllErrors([
   this.getConfig(),
    this.getUser(),
    this.checkRussianContext(query)
])

let's test it with some timeout function

const fun = function(txt) {
  return new Promise((yes, no) => {
    setTimeout(function() {
      if (txt === '2' || txt === '3') {
        no(txt + ' error')
      } else {
        yes(txt)
      }
    }, 5000)
  })
}

 promiseAllWithAllErrors([
  fun('1'),
  fun('2'),
  fun('3'),
  fun('4')
]).then(console.log)

output:

time node /tmp/t.js 
[ '1', Error: 2 error, Error: 3 error, '4' ]

real    0m5.205s.    ==> only 5 sec , instead of 5*4 and all answers in one array without interuptions  
user    0m0.071s
sys     0m0.044s
Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

The most overlooked caveat of async-await is that we have to wrap it in a try-catch block to handle errors by catching rejected promises.

Collapse
 
thibmaek profile image
Thibault Maekelbergh

I don't see why this would be considered a caveat? Thenable promises also need to explicitly declare a Promise#catch() to handle errors? What makes it different from wrapping async/await in try-catch?

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

I mean it's something to be aware of and it's often overlooked and not mentioned at all in articles discussing and guiding on async-await.

The difference between this and promises is that catch callbacks can be put specifically in any place in a promise chain. Of course, we can also do this with try-catch around a single statement, but that gets ugly pretty fast, especially if we want to keep the same variable scope between related try-catch blocks.

Collapse
 
yawaramin profile image
Yawar Amin

Christopher, great and timely reminder of the danger of async. However I may be missing something but, about your last example:

Although this snippet poses a problem, did you spot it? ... Poor little initBooking will have to wait for both getBasket and fetchOptions to finish before executing even though it has nothing to do with the data they'll fetch.

None of these calls are fetching any data, at least in the code as shown. They can all be run in parallel with Promise.all...

Collapse
 
christopherkade profile image
Christopher Kade

None of these calls are fetching any data

It's an example, the methods in question could be fetching data.

For example getBasket could fill the store's basket state variable needed by fetchOptions. I simply wasn't going to show the contents of these methods as they don't seem relevant to the point I'm making.

Thank you for your feedback Yawar !

Collapse
 
mesaquen profile image
Mesaque Francisco

First of all, thanks for the article. I really enjoyed it, but something is bugging me, though.

When you say that "unrelated code shouldn't wait...", I think that there is something we're not addressing here, which is:

Unrelated code shouldn't be in the same function.

My approach on that would be:

1 - Split each block of unrelated code into its own async function. That will keep scope smaller and easy to keep track of what is happening at that moment.
2 - The main function would end up being a point where each step (each block of unrelated code) of the process are invoked in a meaningful order.

Collapse
 
christopherkade profile image
Christopher Kade

Of course, but we must take into account use-cases where our code is running inside a hook for example (mounted, created etc.), or when dealing with legacy code.

The right thing to do would be refactoring it to fit what you mentioned, but we don't always have that option.