Tales from the Evil Empire

Captain Obvious has something to tell us:

Asynchronous methods can call synchronous ones, but synchronous methods can’t call asynchronous methods, or they must become asynchronous.

Duh.

This can never work:

api
  .then(function thenRegisterNextTick(next) {
    process.nextTick(function onTick() {
      api.finally(next);
    });
  })
  .finally(done);

The “next” callback function gets called from a promise the execution of which depends on the completion of the “then” call. This is a deadlock, albeit a subtle one.

The media library picker field does a fine job of integrating and rendering external videos such as YouTube videos. If you want to customize the rendering of the videos, however, you’ll have to deal with the OEmbedPart (obtainable from contentItem.As<OEmbedPart>()). OEmbed is a fairly relaxed protocol that is designed to enable the integration of bits of a site into another. It can deal with images, videos, or even arbitrary HTML. Because it is so vague in what it can do, it’s rather hard to give it a representation other than something completely dynamic, and that's exactly what OEmbedPart is doing. Its only structured property is Source, which is the URL of the original content, one of the only constants in the data. The rest is available through the part’s indexer, by name: part[“title”] for example.

One more thing about fluent asynchronous APIs… Because synchronous methods are changed into asynchronous ones by the flasync helper, internal calls of a synchronous method would in principle also have to be asynchronous calls. That would go against the requirements that I’ve set in the first post to provide a way for API authors to write code that is as close as possible to what they would write in a regular API.

As I said at the end of the previous post, I really thought that a promise library, Q in particular, would help, and would enable me to get rid of my helper library. It turns out, after I tried to make it work, that it won’t. The reasons have to do , among other things, with how hard it is to chain a new asynchronous method onto an existing promise, a strange limitation of those libraries. Well, in fact you can very well create a new promise that combines the old one and a new one for the new asynchronous operation, but that would mean managing a list of promises instead of managing the todo list of callbacks I have in my own helper. In other words, I would still have to maintain a helper that would be, maybe, marginally simpler than what I have now, except that it would require a dependency on another much more complex library that I didn’t write.

In this third post, I’ll show the inner workings of the little helper library that I wrote to build fluent asynchronous APIs. As you’ll see, it’s not simple, but analyzing it does, I hope, give interesting insights about asynchronous programming.

In the first post of this series, I established my requirements for a fluent asynchronous API, and showed what using such an API looks like. In this post, I’ll show what the code for the API itself looks like. On this side of things, the requirements are that writing synchronous methods in such an asynchronous API should look as close as possible to writing the same methods in a synchronous API.

Today I built a fluent asynchronous API. This is hard to do if you want the API to remain as close as possible to a synchronous API, but still maintain reliable and consistent asynchronous behavior. There are examples of this around (Erik Meijer’s reactive extensions come to mind), quite a few –not always clear– blog posts, a general functional pattern, and a few npm packages. None of this however seemed to correspond exactly to what I wanted.