Node.js Async Await in ES7

短命女 2022-07-16 02:57 177阅读 0赞

原文 http://stackabuse.com/node-js-async-await-in-es7/

![Node.js Async Await in ES7][]

One of the most exciting features coming to JavaScript (and therefore Node.js) is the `async`/`await` syntax being introduced in [ES7][]. Although it's basically just syntactic sugar on top of Promises, these two keywords alone should make writing asynchronous code in Node much more bearable. It all but eliminates the problem of [callback hell][], and even let's us use control-flow structures around our asynchronous code.

Throughout this article we'll take a look at what's wrong with Promises, how the new `await` feature can help, and how you can start using it right now.

### The Problem with Promises ###

The concept of a "promise" in JavaScript has been around for a while, and it's been usable for years now thanks to 3rd party libraries like [Bluebird][] and [q][], not to mention the recently added native support in ES6.

They've been a great solution to the problem of callback hell, but unfortunately they don't solve all of the asynchronous problems. While a great improvement, Promises leave us wanting even more simplification.

Let's say you want to use Github's REST API to find the number of stars a project has. In this case, you'd likely use the great [request-promise][] library. Using the Promise-based approach, you have to make the request and get the result back within the callback you pass to `.then()`, like this:

This will print out something like:

$ node index.js
    Camo has 1,000,000 stars!

Okay, maybe that number is a slight exaggeration, but you get the point ;)

Making just one request like this isn't too hard with Promises, but what if we want to make the same request for lots of different repositories on GitHub? And what happens if we need to add control flow (like conditionals or loops) around the requests? As your requirements become more complicated, Promises become harder to work with and still end up complicating your code. They're still better than the normal callbacks since you don't have unbounded nesting, but they don't solve all of your problems.

For more complicated scenarios like the one in the following code, you need to get good at chaining Promises together and understanding when and where your asynchronous code gets executed.

"use strict";
    
    var request = require('request-promise');
    
    var headers = {  
        'User-Agent': 'YOUR-GITHUB-USERNAME'
    };
    
    var repos = [  
        'scottwrobinson/camo',
        'facebook/react',
        'scottwrobinson/twentyjs',
        'moment/moment',
        'nodejs/node',
        'lodash/lodash'
    ];
    
    var issueTitles = [];
    
    var reqs = Promise.resolve();
    
    repos.forEach(function(r) {  
        var options = { url: 'https://api.github.com/repos/' + r, headers: headers };
    
        reqs = reqs.then(function() {
            return request.get(options);
        }).then(function(body) {
            var json = JSON.parse(body);
    
            var p = Promise.resolve();
    
            // Only make request if it has open issues
            if (json.has_issues) {
                var issuesOptions = { url: 'https://api.github.com/repos/' + r + '/issues', headers: headers };
                p = request.get(issuesOptions).then(function(ibody) {
                    var issuesJson = JSON.parse(ibody);
    
                    if (issuesJson[0]) {
                        issueTitles.push(issuesJson[0].title);
                    }
                });
            }
    
            return p;
        });
    });
    
    reqs.then(function() {  
        console.log('Issue titles:');
        issueTitles.forEach(function(t) {
            console.log(t);
        });
    });

Note: Github aggressively rate-limits unauthenticated requests, so don't be surprised if you get cut off after running the above code only a few times. You can increase this limit by [passing a client ID/secret][passing a client ID_secret].

At the time of this writing, executing this code would yield the following:

$ node index.js
    Issue titles:  
    feature request: bulk create/save support  
    Made renderIntoDocument tests asynchronous.  
    moment issue template  
    test: robust handling of env for npm-test-install

Just by adding a `for` loop and an `if` statement to our asynchronous code makes it much harder to read and understand. This kind of complexity can only be sustained for so long before it becomes too difficult to work with.

Looking at the code, can you immediately tell me where the requests are actually getting executed, or in what order each code block runs? Probably not without reading through it carefully.

### Simplifying with Async/Await ###

The new `async`/`await` syntax allows you to still use Promises, but it eliminates the need for providing a callback to the chained `then()` methods. The value that would have been sent to the `then()` callback is instead returned directly from the asynchronous function, just as if it were a synchronous blocking function.

let value = await myPromisifiedFunction();

While seemingly simple, this is a huge simplification to the design of asynchronous JavaScript code. The only extra syntax needed to achieve this is the `await` keyword. So if you understand how Promises work, then it won't be too hard to understand how to use these new keywords since they build on top of the concept of Promises. All you really have to know is that any Promise can be`await`\-ed. Values can also be `await`\-ed, just like a Promise can `.resolve()` on a integer or string.

Let's compare the Promise-based method with the `await` keyword:

Promises

var request = require('request-promise');
    
    request.get('https://api.github.com/repos/scottwrobinson/camo').then(function(body) {  
        console.log('Body:', body);
    });

await

var request = require('request-promise');
    
    async function main() {  
        var body = await request.get('https://api.github.com/repos/scottwrobinson/camo');
        console.log('Body:', body);
    }
    main();

As you can see, `await` indicates that you want to resolve the Promise and not return that actual Promise object as it would normally. When this line is executed, the `request` call will get put on the event loop's stack and execution will yield to other asynchronous code that is ready to be processed.

The `async` keyword is used when you're defining a function that contains asynchronous code. This is an indicator that a Promise is returned from the function and should therefore be treated as asynchronous.

Here is a simple example of its usage (notice the change in the function definition):

async function getCamoJson() {  
        var options = {
            url: 'https://api.github.com/repos/scottwrobinson/camo',
            headers: {
                'User-Agent': 'YOUR-GITHUB-USERNAME'
            }
        };
        return await request.get(options);
    }
    
    var body = await getCamoJson();

Now that we know how to use `async` and `await` together, let's see what the more complex Promise-based code from earlier looks like now:

"use strict";
    
    var request = require('request-promise');
    
    var headers = {  
        'User-Agent': 'scottwrobinson'
    };
    
    var repos = [  
        'scottwrobinson/camo',
        'facebook/react',
        'scottwrobinson/twentyjs',
        'moment/moment',
        'nodejs/node',
        'lodash/lodash'
    ];
    
    var issueTitles = [];
    
    async function main() {  
        for (let i = 0; i < repos.length; i++) {
            let options = { url: 'https://api.github.com/repos/' + repos[i], headers: headers };
            let body = await request.get(options);
            let json = JSON.parse(body);
    
            if (json.has_issues) {
                let issuesOptions = { url: 'https://api.github.com/repos/' + repos[i] + '/issues', headers: headers };
                let ibody = await request.get(issuesOptions);
                let issuesJson = JSON.parse(ibody);
    
                if (issuesJson[0]) {
                    issueTitles.push(issuesJson[0].title);
                }
            }
        }
    
        console.log('Issue titles:');
        issueTitles.forEach(function(t) {
            console.log(t);
        });
    }
    
    main();

It is certainly more readable now that it can be written like many other linearly-executed languages.

Now the only problem is that each `request.get()` call is executed in series (meaning each call has to wait until the previous call has finished before executing), so we have to wait longer for the code to complete execution before getting our results. The better option would be to run the HTTP GET requests in parallel. This can still be done by utilizing `Promise.all()` like we would have done before. Just replace the `for` loop with a `.map()` call and send the resulting array of Promises to `Promise.all()`, like this:

// Init code omitted...
    
    async function main() {  
        let reqs = repos.map(async function(r) {
            let options = { url: 'https://api.github.com/repos/' + r, headers: headers };
            let body = await request.get(options);
            let json = JSON.parse(body);
    
            if (json.has_issues) {
                let issuesOptions = { url: 'https://api.github.com/repos/' + r + '/issues', headers: headers };
                let ibody = await request.get(issuesOptions);
                let issuesJson = JSON.parse(ibody);
    
                if (issuesJson[0]) {
                    issueTitles.push(issuesJson[0].title);
                }
            }
        });
    
        await Promise.all(reqs);
    }
    
    main();

This way you can take advantage of the speed of parallel execution and the simplicity of `await`.

There are more benefits than just being able to use traditional control-flow like loops and conditionals. This linear approach lets us get back to using the`try...catch` statement for handling errors. With Promises you had to use the`.catch()` method, which worked, but could cause confusion determining which Promises it caught exceptions for.

So now this...

request.get('https://api.github.com/repos/scottwrobinson/camo').then(function(body) {  
        console.log(body);
    }).catch(function(err) {
        console.log('Got an error:', err.message);
    });
    
    // Got an error: 403 - "Request forbidden by administrative rules. Please make sure your request has a User-Agent header..."

...can be expressed like this:

try {  
        var body = await request.get('https://api.github.com/repos/scottwrobinson/camo');
        console.log(body);
    } catch(err) {
        console.log('Got an error:', err.message)
    }
    
    // Got an error: 403 - "Request forbidden by administrative rules. Please make sure your request has a User-Agent header..."

While it's about the same amount of code, it is much easier to read and understand for someone transitioning to JavaScript from another language.

### Using Async Right Now ###

The async feature is still in the proposal stage, but don't worry, there are still a few ways you can use this in your code right now.

#### V8 ####

While it hasn't quite made its way in to Node yet, the V8 team has [stated publicly][]their intention to implement the `async`/`await` feature. They've even already committed the prototype runtime implementation, which means harmony support shouldn't be too far behind.

#### Babel ####

Arguably the most popular option is to transpile your code using [Babel][] and its various plugins. Babel is extremely popular thanks to its ability to mix and match ES6 and ES7 features using their plugin system. While a bit more complicated to get set up, it also provides a lot more control to the developer.

#### Regenerator ####

The [regenerator][] project by Facebook doesn't have as many features as Babel, but it is a simpler way to get async transpiling working.

The biggest problem I've had with it is that its errors aren't very descriptive. So if there is a syntax error in your code, you won't get much assistance from regenerator in finding it. Other than that, I've been happy with it.

#### Traceur ####

I don't have any experience with this one personally, but [Traceur][] (by Google) seems to be another popular option with a lot of available features. You can find more info [here][] for details on what ES6 and ES7 features can be transpiled.

#### asyncawait ####

Most of the options available to you involve either transpiling or using a nightly build of V8 to get `async` working. Another option is to use the [asyncawait][]package, which provides a function to resolve Promises similarly to the `await`feature. It is a nice vanilla ES5 way of getting similar-looking syntax.

### Conclusion ###

And that's it! Personally, I'm most excited about this feature in ES7, but there are some other [great features in ES7][ES7] that you should check out, like class decorators and properties.

Do you use transpiled ES7 code? If so, which feature has been the most beneficial to your work? Let us know in the comments!

[Node.js Async Await in ES7]: http://stackabuse.com/content/images/2016/05/node-async-await-es7.jpg
[ES7]: https://github.com/hemanth/es7-features
[callback hell]: http://stackabuse.com/avoiding-callback-hell-in-node-js/
[Bluebird]: https://www.npmjs.com/package/bluebird
[q]: https://www.npmjs.com/package/q
[request-promise]: https://www.npmjs.com/package/request-promise
[passing a client ID_secret]: https://developer.github.com/v3/#increasing-the-unauthenticated-rate-limit-for-oauth-applications
[stated publicly]: https://groups.google.com/forum/#!topic/v8-users/rGgUWxckYfM
[Babel]: https://babeljs.io/
[regenerator]: https://github.com/facebook/regenerator
[Traceur]: https://github.com/google/traceur-compiler
[here]: https://github.com/google/traceur-compiler/wiki/LanguageFeatures
[asyncawait]: https://www.npmjs.com/package/asyncawait