Having written plenty of callback-heavy JavaScript, I was excited to give this thing a go and see how much simpler it could make my code.

What have generators got to do with async?

On the surface, nothing. Generators are a way of returning an arbitrary sequence of results from a function, with the function’s execution suspended in between results. Here’s one:

// This is a generator function. The star preceding the function name means
// it will return a 'generator' object, even though none of the code inside
// explicitly says so.
function *getAllSquareNumbers() {
    for (var i = 1; ; i++) {
        // Every time we 'yield', this function's execution pauses until
        // the generator is restarted by a call to 'next' (see below).
        yield i * i;
    }
}
 
// Now let's fetch some values
var generator = getAllSquareNumbers();
console.log(generator.next().value); // Outputs '1'
console.log(generator.next().value); // Outputs '4'
console.log(generator.next().value); // Outputs '9'
console.log(generator.next().value); // Outputs '16'
// We could go on. That's enough.

Each time you call the generator’s next function, it returns an object of the form { value: ..., done: ... }, where value is the next thing to be yielded by the generator function, and done is a boolean that becomes true if the generator function has exited (e.g., by calling return).

For C# developers, this is exactly equivalent to how the yield keyword has worked since C# 2.0 in 2005.

So again, how does this help with async programming?

When I first heard about Koa eliminating callbacks, I thought “Oh I see, I guess the generator emits values asynchronously“. This turns out to be completely incorrect, and in fact doesn’t even make sense when you have a clear mental picture of generators. But because I was fixated on this (wrong) view of how Koa would work, I was totally confused for some time, and couldn’t make it do what I thought it should do. Allow me to spare you any such confusion.

Generators yield values synchronously

They cannot yield values asynchronously. It wouldn’t make sense for them to do so, because the code receiving these values doesn’t necessarily know anything about ES6 Generators, and it’s always been a basic axiom of JavaScript that your code’s execution can’t be blocked (except now for functions that opt in by having a star in their name, i.e., generator functions). So when you call generator.next() from regular code, you will receive the next value synchronously.

Well then, for the third time, how are generators going to help us with async code, considering that they have to be synchronous?

What if the sequence of values returned was in fact a sequence of promises, or other objects that describe asynchronous tasks? In that case, the code consuming the sequence could choose to wait for each one to complete before calling .next to get the next one. And that’s how Koa works – your application code is the generator, it emits a series promises (or other things I’ll show below), and Koa waits for each one to complete before resuming your code (passing back to you the result of the previous task).

And how does Koa pass back results into your generator? That’s another feature of ES6 generators. If you pass a value to next, e.g., generator.next(123), then that value is given to the generator code as the value of the currently-blocked yield expression. Hence code like var nextData = yield something; (it emits something, then some time later receives nextData).

Koa Example

Here, then, is a trivial Koa example:

var koa = require('koa'),
    app = koa();
 
app.use(function *() {
    // Here is the important bit of application logic for this example.
    // We make use of a series of async operations without callbacks.
 
    var city = yield geolocation.getCityAsync(this.req.ip);
    var forecast = yield weather.getForecastAsync(city);
 
    this.body = 'Today, ' + city + ' will be ' + forecast.temperature + ' degrees.';
});
 
app.listen(8080);

The application code provided to Koa is a generator function (in this case, an anonymous generator function, hence function *() { ... } ). Each yield expression supplies a promise (or other task description) to Koa and suspends execution. Koa waits for each such promise to complete, then resumes your generator, passing you the most recent async result value.

The net result is that you get to consume asynchronous operations using a syntax that barely differs from if they were synchronous.

Error handling

Also great news is that error handling works really cleanly too. If the async task reports an error (for example, promises have ‘failure’ callbacks), then Koa uses the generator’s throw feature to dispatch an exception to whatever yielded that task. You can therefore catch exceptions just like in synchronous code, or let them cause the request to fail (instead of being silently ignored, as async exceptions often are by mistake).

Doing async Koa, or “What can I yield?”

I looked for this info in the Koa docs and couldn’t find it, so here is a list of the possible things you can yield to Koa and have it work properly.

In fact this turns out to be documented for the co Node module, which is what Koa uses behind the scenes.

1. Promises

Typically the most convenient. If you have any library that describes async tasks as Promise-like objects, you can just yield them to Koa. Example:

// Example of a manually-constructed promise using the 'Q' promises library
var Q = require('q');
 
function delay(milliseconds) {
    var deferred = Q.defer();
    setTimeout(deferred.resolve, milliseconds);
    return deferred.promise;
}

Now inside an app.use generator you can do this to insert a pointless delay:

app.use(function *() {
    yield delay(100); // Note: this yield has no useful return value
});

Or for a more realistic example, you can use Q’s denodify feature to create a version of the request module that returns promises:

var request = Q.denodeify(require('request'));
 
// Example of calling library code that returns a promise
function doHttpRequest(url) {
    return request(url).then(function(resultParams) {
        // Extract just the response object
        return resultParams[];
    });
}

And now inside your app.use generator you can:

app.use(function *() {
    // Example with a return value
    var response = yield doHttpRequest('http://example.com/');
    this.body = "Response length is " + response.body.length;
});

Yay, HTTP requests with no callbacks!

Note: This works with any “thenable”, which is the looser notion of a promise defined in the Promises/A+ spec. Every sane promises library conforms to this.

2. Thunks (ignore these if you’re not comfortable passing around function objects)

Thunks? Huh? Koa understands thunks to be functions you call with a single parameter, callback, to receive a result value (or error description) when it’s done.

To begin, let’s imagine you have the following existing code that uses Node.js’s traditional callback style to return a result. Ignore the fact that this totally does not need to be asynchronous. Imagine it’s a database query or something.

// Traditional Node-style callback async pattern (neither a promise nor a thunk)
function getSquareValueAsync(num, callback) {
    setTimeout(function() {
        var result = num * num;
        callback(/* error: */ null, result);
    }, 500);
}

Now, Koa can’t understand this function directly, because it has no idea how many (or what) parameters it takes. But you can turn it into a thunk by wrapping it as follows:

// Wrap the async operation in a 'thunk' so that Koa understands it
function getSquareValueThunk(num) {
    // A 'thunk' returns a function that accepts a callback
    return function(callback) {
        getSquareValueAsync(num, callback);
    };
}

The whole point of this wrapping is to eliminate all parameters other than callback, so that Koa knows how to consume it. Now you can yield this thunk to Koa inside any of your app.use generators, e.g.,

app.use(function *() {
    var square = yield getSquareValueThunk(16);
    this.body = "Square of 16 is " + square;
});

To clarify, calling getSquareValueThunk(16) does not actually do anything except create and return a new function instance, i.e., a function that takes a single callback parameter. Whenever you yield a Function instance to Koa, then Koa assumes it may invoke it with a single callback parameter, and that callback will eventually be invoked as callback(error, result).

If you don’t like or understand this, just use promises. Promises are almost certainly a better choice for application code. Thunks are only good as a low-level primitive used internally by Koa because they don’t involve any particular promises library.

3. Generators

OK, here it gets interesting. Generators can emit generators which emit generators, etc. This makes it possible to construct async tasks out of other async tasks, with arbitrary nesting.

Imagine we want to invoke getSquareValueThunk multiple times in series, and wrap that series up as a single operation. Easy: just make another generator.

function *getSquareOfSquareOfSquare(num) {
    // Each of these is an async operation
    var square = yield getSquareValueThunk(num);
    var squareOfSquare = yield getSquareValueThunk(square);
    return yield getSquareValueThunk(squareOfSquare);
}

Notice the star preceding the function name. This means it’s legal to use yield inside it, and that it returns a generator. This generator returns a series of thunks (though promises would work equally). Now you can insert this series into your async pipeline by yielding it from any app.use code:

app.use(function *() {
    var bigNumber = yield getSquareOfSquareOfSquare(16);
    this.body = "16 to the 8th power is " + bigNumber;
});

This is how a nontrivial Koa app will be structured. The top-level app.use generators will yield generators returned by mid-tier application code (such as business logic) which in turn will yield generators returned by lower-level application logic (such as data access). All the way down, your source code looks synchronous (no callbacks), but is actually fully async. Of course you aren’t necessarily doing three-tier architecture, but you get the idea

Just as an aside, this technique could be used to simplify the doHttpRequest function you saw earlier in this blog post. The original version is:

function doHttpRequest(url) {
    return request(url).then(function(resultParams) {
        return resultParams[];
    });
}

… and it can be replaced with the following generator, with no need for a then callback:

function *doHttpRequest(url) {
    var resultParams = yield request(url);
    return resultParams[];
}

4. Arrays

If you have multiple simultaneous tasks and want to wait for all of them, just yield an array of them, e.g.,

app.use(function *() {
    var urls = [
        'http://example.com/',
        'http://twitter.com/',
        'http://bbc.co.uk/news/'
    ];
 
    // On this line, all three requests begin in parallel
    // Note: doHttpRequest is defined earlier in this blog post
    var arrayOfPromises = urls.map(doHttpRequest);
 
    // When we yield the array of promises here, Koa will
    // wait for all of them to complete
    var arrayOfResponses = yield arrayOfPromises;
 
    this.body = "Results";
    for (var i = ; i < urls.length; i++) {
        this.body += '\n' + urls[i] + ' response length is '
              + arrayOfResponses[i].body.length;
    }
});

As you can see, the result of yield arrayOfPromises; is another array, with the corresponding entries being the promise results.

The array you yield doesn’t have to be purely promises – it can also contain thunks, generators, other arrays, or key-value objects (see below). The structure can be nested arbitrarily.

5. Key-value objects

If you have multiple simultaneous tasks you want to wait for, and you want to give useful names to each of them, use an object. Example:

app.use(function *() {
    var tasks = {
        imposeMinimumResponseTime: delay(500),
        fetchWebPage: doHttpRequest('http://example.com/'),
        squareTenSlowly: getSquareValueThunk(10)
    };
 
    // All of the operations have already started. Yielding
    // the key-value object to Koa just makes it wait for them.
    var results = yield tasks;
 
    this.body = 'OK, all done.';
    this.body += '\nResult of waiting is: ' + results.imposeMinimumResponseTime; // Displays: undefined
    this.body += '\nWeb page status code is: ' + results.fetchWebPage.statusCode; // Displays: Typically 200 in this case
    this.body += '\nSquare of ten is: ' + results.squareTenSlowly; // Displays: 100
});

It’s just easier to read than referring to your tasks as tasks[0], tasks[1], etc.

Isn’t this a lot like C# 5′s async and await?

Yes, very much like that indeed! The * in function *() { } plays a similar role to C#’s async keyword, and JavaScript’s yield (at least when used inside Koa or a similar framework) plays a similar role to C#’s await.

The usage patterns of */async and yield/await are very similar. The main differences are to do with the underlying implementation. In C#, await handles asynchrony as a language feature and has a built-in standard notion of Task, whereas in JavaScript, yield can be used to handle asynchrony (when you supply some library code to describe async tasks and some other library code to wait for them), but it can also be used for other things, and the JavaScript language doesn’t know or care what you’re using yield for.

For C# developers, it would be fun to use the same technique to recreate C# 5′s async/await patterns purely using C# 2.0′s yield keyword.

Learning more about Koa

This blog post is purely about generators and async in Koa. If you want to actually build an app with Koa, go and read the framework’s website. If you’ve never used Express (the earlier incarnation of Koa’s ideas) then be sure to learn about middleware, the central architectural pattern in Koa, so you will see how the framework intends your application to be organised.