{"id":2665,"date":"2018-03-28T15:01:12","date_gmt":"2018-03-28T15:01:12","guid":{"rendered":"https:\/\/solutionstreet.com\/blog\/?p=2665"},"modified":"2018-03-28T15:01:12","modified_gmt":"2018-03-28T15:01:12","slug":"its-getting-better-all-the-time-making-the-complex-simple-using-asyncawait-in-javascript","status":"publish","type":"post","link":"https:\/\/www.solutionstreet.com\/blog\/2018\/03\/28\/its-getting-better-all-the-time-making-the-complex-simple-using-asyncawait-in-javascript\/","title":{"rendered":"It’s Getting Better All The Time – Making the Complex Simple Using Async\/Await in JavaScript"},"content":{"rendered":"

\"guitarguytitle2\"<\/a><\/p>\n

 <\/p>\n

The famous line from a Beatles song also pertains to the JavaScript language. The JavaScript of years gone past in the late 90s has certainly come a long way from its early adoption. No one could have foreseen its rise to power and usage. <\/p>\n

 <\/p>\n

JavaScript seems to be everywhere nowadays including on the server with Node.js<\/a>. I\u2019m fascinated with the potential of using one software language on both the client and the server. Clearly, JavaScript has won in every sense of the word on the client in that every popular front-end framework seems to be written in JavaScript. However, asynchronous coding on the client is still often difficult. On the server, here at Solution Street, we haven\u2019t seen as much interest in using Node.js as a server-side enterprise solution compared to the equivalent solutions found in Java, C#, Python, or Ruby. With callback hell<\/a> and the lack of simplistic sequential processing flow for our \u201cfor\u201d loops and \u201cif\u201d statements when making asynchronous calls, JavaScript may be a language not initially considered for complex server implementations or even ones with large quantities of business logic. However, with the support of async\/await<\/a>, I believe that developers are now positioned and better equipped to use JavaScript on the server in larger numbers (and have an easier time on the client as well) that could lead to a spike in server-side JavaScript usage.<\/p>\n

 <\/p>\n

In this article, we will walk through examples showing how asynchronous calls can be simplified with the inclusion of async\/await. These examples are front-end examples, but the same basic structure would apply on the server. First, before you go any further you must have a basic understanding of callbacks, Promises, and the event loop. Here is an excellent explanation of callbacks (and more)<\/a> and Promises, and here is an outstanding video on the event loop<\/a>. Once you\u2019re up to speed, let\u2019s move on.<\/p>\n

 <\/p>\n

\"callbackcrop<\/a><\/p>\n

 <\/p>\n

In general, with asynchronous calls we are typically dealing with file IO, database calls, or APIs. I may read a file and wait for the results. I may select data from the database and wait for the rows to be returned. I may call an external API and wait for the JSON to be returned. With respect to any of these possibilities, whether on the client or on the server, all of these are relatively the same when it comes to asynchronous interaction. <\/p>\n

 <\/p>\n

With async\/await<\/a>, we can return to our more simplistic control flow structures in our code. Now we have the tools to simplify the complex and write less code<\/a>. <\/p>\n

 <\/p>\n

I\u2019d like to focus on what developers deal with the most in terms of what might be referred to as patterns or just general\/typical business logic and flow. Here is a list of six:<\/p>\n

 <\/p>\n

    \n
  1. Performing some basic asynchronous call (again this could be retrieving a list of data from the database or executing some RESTful API call).<\/li>\n
  2. Performing the above (#1) several times in some chained\/sequential fashion – for example, first I get a customer record, then I get the list of accounts for that customer, and then I get a list of transactions for each account. Of course in database speak we would use a join on the server, but you can certainly envision cases where these are API calls where you have no control over the underlying details and you must make these three independent calls sequentially.<\/li>\n
  3. Performing the above (#1) several times in some parallel fashion – for example, I can get financial transactions for different sets of accounts at the same time.<\/li>\n
  4. For loops (and if conditions).<\/li>\n
  5. Error handling (validation errors).<\/li>\n
  6. Exception handling (something didn\u2019t go as planned with the call or connection).<\/li>\n<\/ol>\n

     <\/p>\n

    Before we start with the examples, let\u2019s discuss a few important points about async\/await:<\/p>\n

     <\/p>\n