Async and Await
This is a good overview of promises and async &#x2F; await. The initial thesis of this seems to be that you need promises or async &#x2F; await to avoid callback hell which I disagree with. You can still write good code, not use promises or async &#x2F; await and not run into callback hell.<p>The example given in the article of callback hell isn&#x27;t even a very good one. Why are we using an asynchronous method to fetch users, another asynchronous method to filter them and yet a third one to get their likes and return those. If that&#x27;s the ultimate goal then, depending on your backend, you can should be able to make that <i>in a single call</i>.<p>But let&#x27;s ignore the poor example in the article. Let&#x27;s say we need to make 3 calls to 3 asynchronous functions and the result ultimately needs to be returned after all 3 functions are finished executing. Do you just nest them like the article? Absolutely not.<p>Essentially my point is: you can <i>always</i> architect around callback hell and make it better. I&#x27;ve already gotten into projects where I would now consider them &quot;promise hell&quot; where every method returns a promise of a promise of a promise of a promise of a promise and it&#x27;s just maddening to debug.<p>Alternatives to callback hell are always context specific. There is no one-shot-cure-all, in my opinion (not even promises or async &#x2F; await) but there are plenty of steps you can take.<p>- Can I separate or combine at least two of these asynchronous functions?<p>- Can I use a pseudo parallel or serial processing pattern ala async.js?<p>- Can I use a messaging pattern where each message is handled separately with a single callback ala msngr.js or postal.js?<p>- Can I simply create a response building pattern where many asynchronous methods write to the same response object and, when it&#x27;s complete, return it?<p>- Does it make sense to use a promise here? What about the async &#x2F; await pattern?