It’s asynchronous all the way down

Captain Obvious 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.

What does that mean for the Node.js developer however? Well, it means that when building infrastructure pieces for an application, if anything a method is going to call into has any chance of being, or of becoming asynchronous, then that method itself needs to be asynchronous. More or less, that in turn means that the lower-level the code is, the more it needs an asynchronous API.

This is really important, and shouldn’t be understated: asynchrony needs to be baked into your applications at the lowest levels as early as possible. If you don’t, a major refactoring is to be expected, and it’s not going to be fun. This is particularly important to keep in mind if you came from a platform that doesn’t put as much an emphasis on asynchrony as Node does.

2 Comments

  • > if anything a method is going to call into has any chance of being, or of becoming asynchronous, then that method itself needs to be asynchronous....More or less, that in turn means that the lower-level the code is, the more it needs an asynchronous API.

    Actually that means that if you build low-level APIs that are synchronous - both synchronous and asynchronous code can call it easily.
    But if you build asynchronous low-level APIs - they are only easily called from asynchronous code. So it means the lower-level the API is the more it needs to be synchronous (so people with either asynchronous or synchronous code can call it) ;-)

    **PS I am being sarcastic and I do get your point - just not well worded in the example**. Maybe a better way of saying it is that it is not about low-level APIs; but more about your overall architecture. If you want everything to be asynchronous.....much better to architect your solution with this in mind from the beginning.

    :-)

    David

  • Actually no. But I may have misunderstood your comment because of my poor mastery of the English language ;) No, more seriously, you're making a good point, but keep in mind that in a web application, the low-level application code is mostly at the beginning of the call stack: from the middleware to the end of the call stack, abstraction tends to grow. The middleware handles the low-level request and response objects, builds abstractions that it then hands down to more specialized, higher-level service objects. Those services may then ultimately deal with lower-level APIs and then it's the other way around, but that's not what I'm talking about in the post, as those are typically not written by the application developer, just used by him, and as you say, are not as problematic because the asynchrony flows the other way.
    In the end, the conclusion is the same, as you point out: you'd better plan for asynchrony from the beginning.

Comments have been disabled for this content.