DEV Community: Roman Sarder

The saga of async JavaScript: CSP

Roman Sarder — Thu, 01 Dec 2022 01:27:49 +0000

Intro

In a previous series, we discovered that it is indeed possible to write our async code in a synchronous fashion using a combination of promises and generators. Our enhanced functions can run asynchronously and independently with the ability to pause and resume on demand. They are much like isolated mini-programs inside our main program! But when you start writing some real-world scenarios, you stumble upon a situation when those tiny independent bits need to communicate with each other and synchronize their execution. In this article we will introduce ourselves to a new pattern that will hopefully allow us to structure our async code with generators in a convenient and scalable way, solving the most common challenges that concurrency presents to us.

What is CSP

CSP stands for Communicating Sequential Processes and is yet another way to model concurrency in our application. CSP is about decomposing your program into a set of independent, self-contained, black-box processes which respond to various events and produce events themselves. To allow these processes to communicate we use channels - a middleman entity that acts like a pipe and distributes events between processes. The way interaction with channels works makes up most of the pattern. There is a strong mathematical theory behind CSP which defines a set of laws and abstractions to make it work but thankfully we don't have to be Ph.D. in Maths to start using it.

An overview

In the real world, things communicate with each other and respond to events. We even tend to think about many things in terms of how they react to events. How could we adopt the right mindset to view the real-world object as a process? We may try to think of something as a set of its reactions to events. Let's imagine a coffee machine. When you turn it on, it heats the water. When you click "Latte", it makes a latte. What about us? When we want a coffee, we go to the coffee machine and make a coffee. When coffee is ready, we drink it. You and a coffee machine are just two processes communicating with each other through an interface. It is the interface that synchronize your actions, and let's you know when the coffee machine finished heating and is ready for you to choose a coffee. Otherwise, without knowing how the mechanism works, your actions would be chaotic and out of order resulting in a broken coffee machine and a solid paycheck. In this particular case, an interface acts like an event channel for the actual coffee-making mechanism inside of our machine and the person. We surely don't need to know about what makes us a coffee behind the curtains as long as we know how to respond to events that it communicates to us.

What is a channel

You can think of a channel as an array of constantly updating pieces of data or events. It might be also similar to a queue in some sense. Anyway, channels represent asynchronous communication between your code. You can take it from the channel and you can put something into the channel. Channels can be buffered or unbuffered, and the buffers can be of different kinds. For example dropping buffer, when full, will drop all incoming values. The sliding buffer will accept an incoming value and drop the oldest element in the buffer. Why would you need buffers? Imagine yourself being a bartender and getting an order for Mojito. Once you are done with Mojito, you ring the bell and expect your order to be taken. Would you sit and wait for somebody to take it before processing other orders? Surely not, you can fit 10 Mojitos on your bar counter, so your "buffer" capacity is 10.

Guarded commands

As we said above, CSP enforces a set of rules when it comes to communication and channels. One of the most important ones is the notion of back pressure. Imagine two people standing on opposite sides of the pipe each having a tap. We cannot push the water to the person on the opposite side until he turns the tap and allows us to deliver it. We need to wait for it. Guarded commands in most of the CSP implementations feature the same concept. We have to wait for somebody to be ready to take out the event from the channel before completing our put operation. The sender process is essentially blocked at this point. When a process wants to receive a an event, it will be blocked as well until an event arrives at the channel. Guarded commands act like a synchronization mechanism that lets two otherwise mostly independent processes sync on particular events.

Show me an example

While learning a pattern, I attempted to create a bare-bones implementation of CSP. Besides getting a deeper understanding of the pattern, another important benefit is that I can show you examples with this library. The code illustrates a super simple coffee machine example I was talking about earlier:

import { makeChannel } from 'csp-coffee/channel';
import { take, put } from 'csp-coffee/operators';
import { go } from 'csp-coffee/go';
import { delay } from 'csp-coffee/utils'

const coffeeMachineInterface = makeChannel<string>();

function* person () {
    yield put(coffeeMachineInterface, 'latte');
    console.log('i want my coffee so much');
    yield take(coffeeMachineInterface);
    console.log('yummy');
}

function* coffeeMaker() {
    const coffeeToMake: string = yield take(coffeeMachineInterface);
    yield delay(1000);
    yield put(coffeeMachineInterface, `have a coffee ${coffeeToMake}`);
}

const { cancellablePromise: personPromise } = go(person);
const { cancellablePromise: coffeeMakerPromise } = go(coffeeMaker);

Promise.all([personPromise, coffeeMakerPromise]).then(() => {
    console.log('done');
})

Note that we expressed our actors as generator functions that are later passed to a special go function. This is what turns our generators into processes. It just takes care of promises, library operators (put, take), and the correct order of their execution. It also returns a promise which resolves when the generator functions is done executing which is handy if we would try to incorporate this library into our code with heavy promise usage.

How does it make things better?

It is not, it is just a different way to organize your asynchronous code. Of course, you would not need such kind of abstraction in every single case. But at some point in developing pretty much any sizeable application, you have to deal with increasing numbers of concurrency problems. And when trying to solve these problems using promises, RxJS, or plain callbacks, you start putting your business code into event handlers. With a growing amount of such code, it is becoming harder and harder to reason about your business logic since you have to assemble a puzzle of callbacks spread all over your application. CSP tackles this issue by introducing channels in the middle, which separates concerns of communication and flow control. It takes all of the good parts of generators - synchronous-looking code, pausing, etc - and takes it to the next level by providing an abstraction for communication and a clear set of rules for it.

Outro

This article appeared to be much shorter than I had previously expected. The amount of methods and functions that CSP might provide to you is overwhelming for one article. What's important is that you are not required to know them all to understand the concept. We took what we learned from the previous article about generators and saw how it could evolve into a much more serious tool. I will leave a few links below for you to explore the API and get a better understanding of what an implementation might be capable of.

Resources

My attempt to port parts of Core Async to JavaScript

Clojure Core Async Library

The saga of async JavaScript: Generators

Roman Sarder — Mon, 27 Sep 2021 15:28:59 +0000

Intro

One of the most complex things in modern JavaScript programs is asynchronicity. We have already taken a look at a couple of existing patterns such as Callbacks, Thunks, and Promises. Although they managed to solve a few key problems, all of these patterns have one major thing in common - they don't look like synchronous code. There has always been a difference between how we write and reason about our asynchronous code. This might sound like an unreal thing to wish for but time proved that we can get really close to it.

What we will learn

In today's article, we will talk about Generators. It's a new type of function introduced in ES6. At first, as we look at it, it will not be immediately obvious how it has anything to do with asynchronous programming. It will most likely seem weird to many of you. But as we slowly going through explanations and examples, we will eventually get to the point where it completely makes sense why we need them in our code. You will discover what makes Generators really stand out and what problems they solve for us. In the end, hopefully, you will be able to articulate about Generators with confidence and justify their usage in your code

Run-to-completion semantics

All normal functions in JavaScript have a common notable feature. When writing our synchronous code, we know that when our function starts executing it will always run to the end and finish before any other function gets a chance to execute. At any given second only one function is able to actively execute. That also means that nothing can pre-emptively interrupt our functions to run something else. The academic term that would perfectly describe all said above is run-to-completion semantics. This is what helps us to not worry about two functions interrupting each other or corrupt our shared memory. By having this "rule" in JavaScript we are able to reason about our code in a pure single-threaded fashion.

Generators are not like that

Generators are a very different type of thing. They don't meet this run-to-completion rule at all. On the surface, it should have brought quite a bit of chaos into our code. But it appears that they provide yet another way to solve our problems, although the way itself might look a bit strange. One way to explain Generators would be to say that in current JavaScript they let us define a state machine - a series of flow from one state to another state with an ability to declaratively list those transitions. I am sure that most of you created quite a few state machines and you might not even know that it is called this way. Previously, there were a lot of efforts and time involved in implementing state machines using available tools in JavaScript. We often used a closure to maintain a current and previous state in a function making all of those transitions, but the code was getting complex, and writing it was time-consuming as well. Generators are adding syntactic sugar which lets you solve the same problem in a lot easier and clear way. But how does that help with async code? To get there, we first need to get a good grasp on the internal plumbings of Generators.

Pausing with yield

Generators introduce a new keyword called yield and it acts a lot like a pause button. So when the generator function is running and it would come across a yield keyword it would demonstrate an interesting behavior. It does not matter where this yield is encountered. It might be even in the middle of an expression, but the generator will pause. From that point nothing will happen in a generator itself, it will stay completely blocked. It literally gets frozen. The important part is that the overall program itself is not blocked and can continue running. The block caused by yield is completely localized. And it can stay in this "paused" state indefinitely until somebody will come and tell it to continue running. You can think of a Generator as a function that can pause and resume as many times as necessary without losing any internal state.

An example

We now have to take a look at an example of Generator to see how all of these concepts stack together. Here is our first generator:

function* helloWorldGenerator() {
  console.log('Hello world');
  yield; // pausing
  console.log('Hello again!')
}

On line 1, the asterisk symbol tells the JavaScript that the function we are defining is indeed a generator. You will notice on line 3 we have our yield keyword which is our pause button. By using yield, the generator itself declares when, where, and in which manner it wants to pause. This is also called cooperative multitasking. Nobody on the outside can come in and interrupt its execution. This is what often causes catastrophes in multi-threaded languages. Fortunately, we don't have those.

Calling a Generator

When calling a Generator it behaves a bit different than other functions. Continuing with an example above, let's illustrate how we could use that generator:

const iterator = helloWorldGenerator();

iterator.next() // Hello world
iterator.next() // Hello again!

When we call the generator function, no code gets executed inside the generator itself. Executing a generator actually does not run any code. What's really happening is that we are getting an iterator. You probably know what are iterators, but just in case let's recall their definition. Iterator is a way of stepping through the set of data one result at a time. In this case, the purpose of the iterator is not to step through a collection of items, but to control our generator from the outside by literally stepping through these yield statements. Think of it as a handy API that helps us to control the flow of our generator. We can't pause a generator, but using an iterator we can ask it to run until it wants to pause itself. So on Line 1 none of the code runs, but on Line 2, by calling .next on the iterator object, we start the generator's execution. It will then execute console.log('Hello world') statement, pause itself on yield and return control back to the client's code. Whenever the next call to .next happens, it will resume the generator, execute the last console.log('Hello again!') statement and at this point, our generator is done.

Yielding values

It appears that in addition to yielding control to our code, generators are also able to yield values as well. In our previous example, we yielded nothing. Let's come up with a dummy example to showcase this point:

function* authorDossierGenerator () {
  const author = {
    name: "Roman",
    surname: "Sarder",
    age: 23,
  }

  yield author.name;
  yield author.surname;
  yield author.age;
}

const iterator = authorDossierGenerator();
iterator.next() // { value: "Roman", done: false }
iterator.next() // { value: "Sarder", done: false }
iterator.next() // { value 23, done: false }
iterator.next() // { value: undefined, done: true }

In the last example we assumed that generator yielded us an undefined, but now we are returning actual values. You will notice that each .next call gives us an object with value and done properties. The value corresponds to what we are yielding from the generator, in this case, it's a bunch of object property values. The done flag indicates whether the generator is complete or not. This might be tricky at the beginning. Our third iterator.next call visually might look like a generator is already done, but it is not. Although it is the last line in the generator, what really happens is that the generator is paused on the last expression which is yield author.age. If it is paused, it can be resumed and that's why only after the fourth .next we are getting done: false. But what about the last value being undefined? As with simple functions, if there is no return statement at the end of the generator, JavaScript assumes that it returns undefined. At any point, you can return from a generator and it will immediately complete itself as well as return a value if any. Think of return as an "Exit" button.

Passing values

We managed to illustrate that there is indeed a way for a generator to pass messages to the client's code. But not only we can yield messages out, but when calling the .next method we can also pass the message in and that message goes right into the generator.

function* sumIncrementedNumbers () {
  const x = 1 + (yield);
  const y = 1 + (yield);
  yield x + y
}

const iterator = sumIncrementedNumbers();

iterator.next() // { value: undefined, done: false } 
iterator.next(5) // { value: undefined, done: false }
iterator.next(2) // { value: 9, done: false }
iterator.next() // { value: undefined, done: true }

Notice that we placed our yield keywords in the middle of both expressions. From the inside perspective, think of those yields as question marks. When the generator gets to the first expression it basically asks a question: Which value should go here? Without an answer, it cannot complete an expression. At this point, it will pause itself and wait for somebody to provide this value. And we do that by calling .next and passing a value of 5. Now it can proceed to the next yield. Those yields act like placeholders for values that will at some point in time be passed to the generator and replace yield to complete an expression.

Converting to async

Right now, you should be ready to look at the following example and not have your head completely blown up. We are going to attempt to use Generators to work with asynchronous code and convert one of our previous examples. It might look a bit awful because of hoisting but think of it as a proof of concept. We will surely refactor into something that looks a lot nicer.

function getData (number) {
  setTimeout(() => {
    iterator.next(number);
  }, 1000)
}

function* sumIncrementedNumbersAsync() {
  const x = 1 + (yield getData(10));
  const y = 1 + (yield getData(20))

  console.log(x + y) // 32
}

const iterator = sumIncrementedNumbersAsync();
iterator.next();

Phew, are you still there? Let's walk through each line of code to get an idea of what's happening. First, we call our generator to produce an iterator and start execution by calling .next. So far so good, no rocket science evolved. Our generator starts calculating a value of x and encounters the first yield. Now the generator is paused and asks a question: What value should go here? The answer lies in a result of getData(10) function call. Here comes the interesting part: our homemade getData function, which is a fake async function, resumes a generator once it is done with calculating value. Here it is just a setTimeout, but it could be anything. So after 1000 milliseconds, our fake getData gives us a response and resumes a generator with the value of response. The next yield getData(20) is processed in a similar way. What we get here is synchronously looking asynchronous code. Our generator now is able to pause itself and resume when the async value is calculated in the exact same manner as it did with synchronous values. That's a huge deal.

The magic key

Because the generator employs this pause/resume thing he is able to block itself and wait for some background process to finish and then resume with the value we were waiting for. Abstract yourself from implementation details because it will be hidden in a library most of the time. What matters is the code inside a generator itself. Compare that to what we have seen in code using Promises. Promises' flow control organizes callbacks vertically into a chain. Think about Callbacks and Thunks - they are nesting those same callbacks. Generators bring their own flow control as well. But the very special feature of this flow control is that it looks completely synchronous. The async and sync code are sitting next to each other on equal terms. Neither do we see any difference nor do we have to think about organizing our async code in a different fashion anymore. Asynchronicity itself now is an implementation detail that we do not care about. It is possible because Generators introduced a syntactic way to hide the complexity of state machines, in our case, asynchronous state machine. You are also getting all of the benefits of synchronous code like error handling. You are able to handle errors in your async code, in the same manner, using try-catch blocks. Isn't that beautiful?

Purging the IOC

As you look at this example more carefully, you might notice that there is one problem with this approach. Our getData function is taking control of executing our generator which leads us to Inversion Of Control. This function gets to call .next method on our generator in an unexpected way and mess everything up and the current codebase has no solution to it. Guess what? We are not afraid of this previously terrifying problem anymore. We just need to recall which pattern has already solved this issue for us. We are going to mix Promises together with Generators! And for this union to happen, instead of yielding undefined we have to yield a promsie.

The ultimate duo

Let's imagine how we could make this work. We've already said that inside of our generator we need to yield a promise. But who will take care of resolving that promise? Well, that would be done by the code that drives the generator, that calls .next. And once it gets a promise it should do something to it, it will have to wait for a promise to resolve and resume a generator. We are in need of an additional abstraction that will do it for us and most likely this will be provided by a framework, or library, or JavaScript itself. It is unlikely to be a practical thing to do - reinventing the wheel each time you want to work with promisified generators. But for educational purposes, we will figure out one ourselves and study it.

Building our Promises Generator runner

I am going to provide you an implementation of such generator runner. Obviously, it lacks some of the features that are absolutely required if you want to use it in production, such as proper handling, but it covers our needs and demonstrates the concept perfectly while keeping things rather simple.

function runner (generatorFunction) {
  const iterator = generatorFunction();

  function nextStep(resolvedValue) {
    const { value: nextIteratorValue, done } = iterator.next(resolvedValue);

    if (done) return nextIteratorValue;

    return nextIteratorValue.then(nextStep)
  }

  return Promise.resolve().then(nextStep)
}

Our runner takes a generator function and produces an iterator as usual. Then it returns a resolved Promise and in .then method we are passing our worker function nextStep. It does a whole job of getting the next iterator value and checking if the generator is done. If not, we are assuming that the result of the .next call was a Promise. So we are returning a new Promise ourselves by waiting for the iterator value Promise to resolve and passing the value to our working function. The worker does the job of passing the result value to the iterator if it needs one and repeating its job until the generator is done. Nothing really complicated.

Working with our Generator Runner

We are going to further modify our sumIncrementedNumbers example to incorporate our new runner and take a look how we consume a promisified generator.

function getData (data) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(data);
    }, 1000)
 })
}

function* sumIncrementedNumbersAsync () {
  const x = 1 + (yield getData(10));
  const y = 1 + (yield getData(20));
  return x + y;
}

runner(sumIncrementedNumbersAsync).then(value => {
  console.log(value) // After ~2000ms prints 32
});

Everything here should already be familiar to you. Since our runner eventually results into a Promise, from the outside world perspective our wrapped generator is nothing more than just another Promise. We have managed to solve non-local, non-sequential reasoning problems using our Generators to make async code look like synchronous one. We have brought Promises to do the dirty job of solving the Inversion Of Control issue and created our simple Promises Generator runner. Finally, we ended up with a clean interface of a Promise as a result and all of the Promises' benefits apply to our wrapped generator. That's why the Generators are so powerful. They completely change the way you write your asynchronous code. They finally provide you the ability to write a code that is intuitive for our brains and does not contradict the way we think.

Async/await ?

In fact, this pattern proved itself so useful that in 2017 ECMAScript rolled out its very own implementation of async generators by introducing async/await keywords. Don't let it fool you, because this feature is completely generator based and the concept is exactly the same. The difference is that now it is a first-class citizen in our language with proper syntax support and we are not required to use any helper libraries to do this job anymore. But there are some caveats with how async/await works right now.

Pure generators vs async/await

How would you cancel an async function and stop it from further execution? The thing is that there is no way to do so. Currently async/await just returns a Promise. That's cool and all, but the ability to cancel is too crucial to ignore. And current implementation just does not give you enough tools for finer control of execution. I am not the one to judge their design decisions but my point is that the API could be further improved to, for example, return both a promise and a cancel function. At the end of the day, we are working with generators that implement a pull interface. We are in control of how to consume an iterator. You could easily imagine how we could just stop consuming it in our runner if we would receive a cancel signal. To prove the point we can introduce a simple change to implement a very primitive cancel mechanism. And you could imagine somebody making a more sophisticated and error-proof variant with a rollback strategy.

function runner (generatorFunction) {
  let isCancelled = false;
  const iterator = generatorFunction();

  function nextStep(resolvedValue) {
    const { value: nextIteratorValue, done } = iterator.next(resolvedValue);

    if (done) return nextIteratorValue;

    if (isCancelled) {
      return Promise.resolve();
    }

    return nextIteratorValue.then(nextStep)
 }

return {
  cancel: () => isCancelled = true,
  promise: Promise.resolve().then(nextStep)
}

This illustrates my point above. We are returning an object both with the Promise and cancel method. The cancel method just toggles a flag variable that is contained via closure. Pretty neat and opens a lot of possibilities for further enhancements.

Outro

That was a lot of stuff to learn and discuss this time. But the topic itself is not the easy one and does not let you spend just 5 minutes of reading to get a grasp on it. I don't expect any of you to become generator experts by just completing this article, but I am pretty sure that I've given you a good start that will push you to further explore the topic yourself. With generators seems like we've answered each of our questions about async programming. We've solved Inversion of Control, we now are able to write synchronous looking asynchronous code, and looks like we've combined the best features from all of the previous patterns. But, as it often happens in Software Engineering, there is often more than one possible answer to the same problem. From this point, the next patterns we see will just offer you brand other ways of solving problems and each of them might be more or less suitable for your case. It's up to you as an engineer to make a final call. It will be completely fine if you quit at this point of the series because for most of us this could be enough to know about asynchronous programming in JavaScript for now. But if you decide to stick with me, we are going to take a look at some of the advanced patterns like CSP and Observables. We will surely have a talk about one of them next time. Thank you for the long read!

Credits

Big thanks to Kyle Simpson and his materials. I was particularly inspired by his Asynchronous JavaScript course and it pushed me to deep dive into these topics a lot harder than I would have done normally.

The saga of async JavaScript: Promises

Roman Sarder — Fri, 17 Sep 2021 15:49:11 +0000

Intro

We have been learning async JavaScript patterns in a way that it should now make sense why Callbacks often might not be a sufficient solution to our day to day problems and how they helped Thunks to evolve into a powerful, lightweight tool. Although it didn't solve trust issues and Inversion of Control problem, the lessons we have learnt eventually resulted into a birth of a next pattern - Promises.

Explaining the approach

Armed with conceptual understanding and knowledge about innovations and drawbacks of Thunks we are now ready to take a look at what Promises can offer to us. We are not going to deep dive into Promise API and overwhelm ourselves with those fancy methods and properties right away. In the end of the day the particular method names and design solutions might differ between implementations, but the essential core idea will always stay the same. We are going to tackle the concept first and see how current JavaScript expresses it in terms of API.

Placeholder

What would be a good real world example of Promises? It appears to be a rather simple thing to explain. Let's imagine ourselves coming to a restaurant. Most of us like burgers of some kind, don't we? So you come and order one. What do you usually get in return? The receipt with order number. Eventually you are going to exchange your receipt for the burger when an order is ready but until then you can safely think and start reasoning about it as if it was already in your hands. The receipt became a placeholder for a future burger. Promises are much like that. For some value that will be fulfilled in the future, you are given a placeholder - a Promise - which later can be "exchanged" for a real value.

Inversion of Control: Round Three

It appears that both Thunks and Promises are following the similar philosophy - they provide you a something which you can work with until the real value shows up. But we had a problem of Inversion of Control with Thunks because they were using callbacks under the hood. We passed a function and hoped for the best. How could you "uninvert" the Inversion Of Control? What if we would be in control of executing the code which will run after the value is ready? Let's reсall a dumb example that we invented to illustrate how serious this problem can get:

fancyAsyncFunctionFromLibrary(function () {
    chargeCreditCard()
})

Pseudocode to the rescue

We are not going to use current Promise API to help ourselves to solve this issue yet. Imagine that you don't have Promises invented at all. Flex you brain cells and try to think of a way to resolve the Inversion Of Control problem in this code using pseudocode. How would we modify an example above in order to get in control of executing our callbacks. Thankfully, there are plenty of patterns in programming that can inspire you. What about Event Emitters?

const futureValuePlaceholder = fancyAsyncFunctionFromLibrary()

futureValuePlaceholder.on('complete', chargeCreditCard);

We made ourselves a fancyAsyncFunctionFromLibrary which now returns an event emitter. Given the knowledge of what events you can get, we can attach our callbacks however we want. In this example, we run our callback once something is completed in that function so we could charge a credit card. We could subscribe to an error event in the same fashion. Or we could decide to not do so. We could even imagine ourselves detaching our listener once a complete event fired. There are plenty of things that we can do using this model. The pseudocode we've written basically says: "Give me an object which fires different events, and I will decide what events I will subscribe to and how I will run my functions in response to them". And the interesting part, it is not looking that different than Promises we use everyday. Instead of on method we have then, which actually knows what event it should subscribe your callback to. Despite the fact that callbacks are still the essential part of our code, we were able to regain the control of the execution and run our functions on our terms using a nice and clean API. To summarise, the other way you can think of Promises is that they are much like Event Emitters. But to solve the Inversion of Control disaster, we need something more than an API. There is a missing part.

Trust enforcing

We still might be in doubt of how our callbacks will be run. There is a list with a decent amount of concerns about callbacks that is menacingly standing right next to our newborn event emitter. We desperately need trust to be introduced to eliminate those. The Promises would not be of much use if they didn't incorporate trust enforcing mechanisms. Thankfully, when you are using Promises in current JavaScript, JavaScript itself ensures that:

promises are immutable
errors are not swallowed
the promise will either succeed or throw an error
it only resolves once
no actions at a distance

Pretty neat, huh? Having a well defined and strict behavior, we are no longer questioning ourselves about the way our callbacks are run. The immutable part is also very important. JavaScript makes sure that when you pass your Promise to a third party code, there is no way that it will somehow get mutated or changed in any way. You simply cannot affect both promise's state and a value inside. No action at a distance. Also our code is now safe from being called multiple times and we are always getting an error no matter what. Even if you are not handling that error explicitly in your Promise, it will bubble up as Unhandled Promise rejection and you will not miss compiler yelling at you.

Show us Promises, sir

Let's take our pseudocode that we wrote before and use Promises this time:

fancyAsyncFunctionFromLibraryWithPromise () {
    return new Promise((resolve, reject) => {
        fancyAsyncFunctionFromLibrary(resolve)
    })
}

fancyAsyncFunctionFromLibraryWithPromise()
    .then(chargeCreditCard)
    .catch(handleError)

Our fancyAsyncFunctionFromLibrary now returns a Promise that we have created ourselves. You are getting a first-class object which you can pass around much like any other value. When constructing a Promise, you pass it a callback which expects two arguments: a resolve and reject functions. These are your tools to switch the state of promise to either a fullfilled state or rejected. We call a then method to attach a callback which will be executed once Promise is fullfilled, in other words resolve function got called inside of our Promise. That callback receives a value of Promise if there is any. On the opposite side there is a catch method for error handling which works in a similar way. We have to handle only two possible cases and we have two corresponding methods that we need. The code itself reads much like human language: "Do something that takes time, then pass it to this function, but if something went wrong, catch the error and pass it to this function".

Flow control

Let's try ourselves in writing some sequence of operations using promises and see how they look like in a bit more common example:

readFileOnePromise
    .then(fileContents => {
        console.log('first file', fileContents)

        return readFileTwoPromise
    })
    .then(fileContents => {
        console.log('second file', fileContents)

        return readFileThreePromise
    })
    .then(fileContents => {
        console.log('third file', fileContents)
    })

This time temporal dependencies between operations don't have to result into more nesting and they all stay on the same level throughout the program. The notable feature which makes working with Promises much easier is chaining.

Chaining

Chaining is some sort of syntax that allows you to do multiple object method calls without intermediate variables. This is achieved by each method returning the object. Inside then method's callback you can either return a Promise or a value. In case you returned a Promise, the next then will not fire its callback until this Promise is resolved. You can handle both in the same way and this results in a time independent value wrapper much like Thunks. But oftentimes it is only API which makes people use Promises and think that they are a silver bullet in a world of async programming. Remember that the important part about Promises is not their API, but their idea and concept which at some time in the past innovated the way you work with asynchronous code in your programs. It is about their ability to finally solve Inversion of Control issue while keeping the advantages of being a container around the data which you can pass around and a placeholder for a future value.

Callbacks.. again?

Yes, we still have callbacks. Actually, if you look at Promises carefully, you would see that they might look like callback managers! And that's the third and final way I was able to think of Promises. They use callbacks for the same well known tasks - running code once something is completed, and in addition they bring in the trust that we needed. The important point in Promises is that they reduce the gap between async and sync code even further. There are two very important things about synchronous functions:

they return value
they throw errors

Promises composition

More importantly, if we are talking about function composition, if any of functions in a composition throws an error, that error bypasses all other composition layers and goes all the way up so the client code would be able to catch it. In case of Callbacks, returning value was impossible since they just were not ready at a moment of call. Similarly, you could not throw errors because there was nobody to catch them and with callbacks you would need to manually propagate those errors. Promises do an important job of bringing back those things into asynchronous world by saying that each function should return a promise and guaranteeing that an error will bubble up. If written correctly, those then/catch blocks compose in a similar manner as their synchronous counterparts by having fulfillments creating a compositional chain with rejections being able to interrupt it at any stage that is only handled by someone who declares that he is ready to handle it.

A bit of functional programming

then method instead of being viewed as "callback attaching mechanism" could be viewed as "trasformation application". It basically allows us to apply transformation on value inside a promise and create a new one which will be passed down the chain. From this point of view, Promises are very similar to Monads with their ability to chain and apply functions on underlying values. Although the current JavaScript API for Promsies itself is not as 100% pure as functional programmers would desire, the monadic nature of promises is quite obvious.

More of fancy API

Promises come with plenty of additional methods to improve your flow control out of the box. Promise.all will take an array of promises and return a new promise which resolves once all promises are resolved. Promise.any is similar in a way that it expects an array of promises, but will return a promise which resolves once at least one promise is resolved. If there are no resolved promises, the result promise gets rejected. I will not go through each and every method on Promise object in JavaScript but you probably get the idea. Promises also provide you some useful abstractions which help you to orchestrate not one, but a group of promises in a more complex scenarios. Once you start discovering the documentation, you will find yourself inventing those abstractions on the fly. Not all of them are currently implemented, but nobody stops you from using third party promise libraries. You can even create one yourself!

Downsides

I noticed that there are some articles about Promises that focus on API misusage when talking about the downsides. There are also many of them which don't talk about any problems with Promises at all. There are a couple of things left that Promises didn't manage to solve or provide. My attitude towards most of the issues with Promises could be described as "Ah, but this and that thing would also be handy, altough it would not make sense in this pattern". Having our main enemy - Inversion of Control - defeated, we are now only looking for more features to make our toolset complete. And you will see that things described below are screaming for another pattern to be created to use alongside Promises. So take these points as "nice to haves" instead of "need to fix".

Still out of main flow

This could be a debatable point. While Promises reduce the number of nested callbacks you are working with, they are not removing them entirely. Using standard Promises, there is no way for our synchronous code to "wait" for promise. Consider this example:

const func = (value) => {
    let promise = somePromiseBasedFunction();

    let promiseValue = ?;
    promise.then(function(result){
        // I can access the value here, but there's
        // no way for me to get it up in the main
        // scope and have `func` return its value
    });

    const finalValue = someOtherFunction(promiseValue);
    return finalValue;
}

Altough the purpose of promises is to not block your program, oftentimes we really need this kind of mechanism to be available. This would close the gap between sync and async code even more. Techically, this got solved in later versions of JavaScript with async/await, but those are based on generators and are subject to a separate article.

Not cancellable

This one also contradicts the ideology behind promises. No doubt, an ability to cancel a promise with an outgoing AJAX request would be super great, but that would also mean that Promises are no longer immutable and suddenly we are now vulnerable to an "action at distance" problem.

Missing abstractions

Just a "nice to have" thing which often makes you create those methods from scratch or use third party library as an alternative. A list of available Promise abstractions implemented currently can feel a bit limiting in some cases. For example, imagine yourself chaining 10 then calls and trying to remember that each time you need to return a Promise to make a composition work. It can easily become annoying and prone to errors when dealing with a long chain. How about sequence method which would accept a variable number of functions and do that for you? It will automatically chain those function calls and ensure that each of them will return whatever the next one needs to make it work. As I said, one could come up with at least a couple of useful methods that are not presented in current API and it would be great to have them implemented in a language itself.

Outro

It has been a great journey. We finally got rid of Inversion of Control problem and by accumulating our knowledge and experience across the patterns we've managed to deep dive into Promises and properly understand why they became a thing. At this point, the creation of Promises should be a pretty obvious thing for you because this pattern is mostly a correction of mistakes from previous ones. They are currently an important and powerful tool in our arsenal and they will stay like this for a while. But the picture of ideal async programmer's life is incomplete and there are missing features and concepts which are to be implemented. Similar to callbacks, Promises themselves will serve as a foundation for a next pattern which will enhance their capabilities to provide us even better experience. As we go further, topics will keep getting more and more challenging, so I am very excited to tell you about other patterns. In next article we will talk about Async Generators and see how async/await feature works under the hood.

The saga of async JavaScript: Thunks

Roman Sarder — Sun, 05 Sep 2021 16:51:35 +0000

Intro

Last time we talked about Callbacks - a pattern that is deceptively easy to understand. The concept which we will discuss today is a next step of evolution and naturally extends the callbacks' capabilities. It also brings us an interesting solution for async programming and most importantly - it shifts our mindset and forces us to look at things from the different perspective. This time I want to provide you a comprehensive explanation on what are thunks and how it can help to organize our code better.

What the hell is that?

For real though, I wish I knew why somebody came out with this name. But jokes aside, thunks are the thing that at some point made me wondering how I had got so far with JavaScript without even knowing how powerful it can be. From a synchronous perspective, thunk is essentially a function that is ready to give you some value back and requires no additional input. As simple as that. Many of you working with React probably know an awesome and plain simple library called redux-thunk which as name suggests is based on thunks. But more on that later. For now let's take a look at a simple example of a synchronous thunk:

function superCalculation() {
    return 9999 + 9999
}

const outFirstThunk = function () {
    return superCalculation()
}

const sum = thunk() // 19998

Here we have a thunk called ourFirstThunk which value is a function and when it gets called it will always return us the same value - the result of out superCalculation.

The part we care about

The important part is that this thunk has become a wrapper around some particular state. In this case it is a result of a potentially expensive operation. Imagine yourself shooting a beautiful moment on vintage film. The film itself is your thunk and the captured moment is the wrapped state. We can now pass this "film" around our app and when we want to extract that state, we simply "develop the film" by calling the thunk and get the value back. Instead of working with the state itself, we are passing a representation of the value. Pattern allows us to conveniently hide the details of underlying computation and provides a common interface. We also managed to delay the calculation until we really need it and it is possible now to inject this operation into different parts of our code. This is what is also called lazy thunk.

Going async

Things start to become quite intriguing when you are thinking about async applications. So how would you possibly describe an async thunk? For the most part it is the same. It's a function which doesn't need any arguments to make its job except for a callback. Interestingly enough despite all of its flaws, callback pattern has managed to find its use here. The standard synchronous implementation does not take time factor into account and we already saw that callbacks are pretty capable of handling "future value processing". Why not use it here as well? Let's extend our previous example to an asynchronous thunk:

function superCalculationAsync (callback) {
    setTimeout(() => {
        callback(9999 + 9999)
    }, 1000)
}

const thunk = function (callback) {
    superCalculationAsync(callback)
}

thunk((result) => {
    console.log(result) // 19998
})

We now have an superCalculationAsync function which fakes an asynchronous behaviour by using setTimeout utility. We then create a thunk which is a function accepting a callback. This callback is passed to superCalculationAsync function to handle the result of the operation. The overall concept stays the same, except for callback coming into play to help us handle things. Still we end up with a handy container which we can use anywhere in our app as long as we pass the callback.

Lazy vs Eager

We managed to convert our synchronous thunk into an asynchronous one. You will notice that our superCalculationAsync itself is not executed right away. This is a lazy thunk. Until the callback is provided, no calculations will fire. Let's try to toy with this example a little bit more and think of the way to rewrite it to eager thunk - the one which will try to run calculations in advance and attempt to give you result back immediately.

const thunk = (function () {
    let thunkResult;
    let handleResult;
    superCalculationAsync(function (result) {
        if (handleResult) {
            handleResult(thunkResult) // result is not ready
        } else {
            thunkResult = result // result is ready
        }
    })

    return function runThunk (callback) {
        if (thunkResult) {
            callback(thunkResult) // result is ready
        } else {
            handleResult = callback // result is not ready
        }
    }
})()

While developing an eager thunk you stumble upon two possible cases that you need to handle. The first case is when thunk is called after the inner operation is completed and we can safely return the result. This is the easy part and it is no different to what we have been doing so far. The second case is something to think about - the thunk is called, but the operation is still going. We have to bridge those two branches of our program somehow. The provided solution is by no means the most performant and elegant one but it gets work done. Here we ended up with two if statements that mirror each other. We call the user's callback with a result of an underlying computation if it is already done. If not, we are injecting the provided callback directly. Client's code will not even know that the thunk might take time to complete.

Power comes with abstraction

Here is the point - we could rewrite our synchronous example with a callback and then treat both an async and sync thunk uniformly. By doing that we are effectively freeing ourselves from dealing with a time factor in our code by having this kind of normalization. We don't have to know or care about the how a value is delivered to us. The first time we call our thunk and pass a callback it might do significant work to get an expected response. It could be an AJAX request, a CPU intensive task or any other crazy stuff which can take a while. But the second time we call it, it might decide to memoize the return value and give it to us right away. A client code using our thunks doesn't need to have any concerns on internal implementation as long as it has the way to work with both synchronous and asynchronous code in the same manner. This is a big step forward. We have produced a wrapper around data that is time independent. And we know that time might be the most complex thing to manage in our applications.

Real world example

I have already mentioned redux-thunk - a library that is recommended to use for handling side effects in redux app according by redux maintainers themselves. It provides us a middleware which expects a thunk or a simple action object and handles them accordingly. It is so dead simple, that main function which creates a middleware is just 9 lines of code.

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => (next) => (action) => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

The code is pretty straightforward and most likely doesn't need any explanation at all. This is conceptually the same thunk we were talking about above. The only difference comes with a few extra arguments that are passed into our thunk - dispatch and getState with dispatch fulfilling a role of a callback.

Simplicity

The great thing about thunks is that this is just a pure JavaScript code. No libraries or frameworks involved. By adopting a different way of thinking, we managed to eliminate a confusing and difficult to handle thing called time. Let it sink for a moment. The mental overhead is gone and replaced with a common interface which represents our value. As a bonus, we are capable of reusing these representations across our code without any problems. But there is a revelation to be made.

The dreaded Inversion of Control issue

I will make this statement right away - thunks were not created to address Inversion Of Control issue. This is not a silver bullet in the world of async programming. In the example above, redux-thunk library has no way to ensure that their dispatch function will be called appropriately. The same is true for our examples. What thunks are effectively doing is that they are laying a foundation for Promises. If you are familiar with promises, and I am pretty sure most of you are, you can notice that thunks are essentially Promises without a fancy API. Yes, we are getting benefits of uniform treatment, reusability and a nice wrapper which encapsulates the details of our computations, but Inversion Of Control issue is still to be solved. Also, because thunks are still using callbacks under the hood, you could easily end up with something that is very similar to Callback Hell. If we try to express several operations that have temporal dependencies between each other, that would become clear. Let's assume that we have a makeThunk utility which accepts a function and a list of parameters which are passed to wrapped to it. For the sake of simplicity I will not provide any implementation details on it, you can find plenty of those on the internet.

const readFirst = makeThunk(readFile, 'first file');
const readSecond = makeThunk(readFile, 'second file');
const readThird = makeThunk(readFile, 'third file');

readFirst((firstFileContents) => {
    console.log('first file contents', firstFileContents);
    readSecond((secondFileContents) => {
        console.log('second file contents', secondFileContents)
        readThird((thirdFileContents) => {
            console.log('third file contents', thirdFileContents)
        })
    })
})

We first precreate three thunks for later use. It is important to understand that readFile is not executed until we pass the callback. On the next lines, we nest thunks executions to get the right order of operations. The rule temporal dependency === nesting holds true here as well.

Outro

Thunks went a long way to improve our JavaScript code. This pattern brings couple of crucial benefits comparing to callbacks and still manages to be lightweight and simple. And the best part is that it is all possible with just the functions' manipulations. As we saw in redux-thunk library example, thunks make handling side effects in our Redux a childsplay in just 9 lines of code. After some practice you could imagine that capabilities of this pattern extend far beyond the scope of just React & Redux apps. Thunks ideologically precede the Promise pattern and these two are much similar. Although thunks didn't manage to solve the Inversion Of Control issue, we will see how the conceptual core of this pattern with an addition of new API finally succeeds. Thank you for a read, keep your eyes on updates and next time we will talk about Promises.

The saga of async JavaScript: Callbacks

Roman Sarder — Tue, 31 Aug 2021 16:28:38 +0000

Intro

The heart of modern JavaScript application lies in its interactivity. Buttons are being clicked, mouse is moving while you are dragging your image to upload a new avatar, AJAX requests is going out to get your favourite feed - all of these can happen while that cute cat video is preloading along with its comments' thread. Thanks to JavaScript being asynchronous, we can leverage those events while keeping the app responsive. Without knowing how to orchestrate those temporal dependencies well, the complexity in our code will quickly get out of hand.

So what's next?

In this series of articles we will try to explore different patterns that help us write asynchronous JavaScript. Most modern libraries and frameworks use at least one of them. And most developers have no idea about their strengths and weaknesses. We will take a look at why those patterns exist. We're gonna explore which problems do they solve, and which they don't. In the end of the series, hopefully, you are going to be familiar enough to know when to use each one of them and reason about this decision. Take your seats, gentlemen, and today we will have a tough talk about callbacks.

Callbacks? We already know those

I get it. It will be a decent challenge to find a JS developer who doesn't have at least a rough idea of what callbacks are. We all know how they look like. You pass the function as an argument and it is called after a certain action is completed. We are going to have a little practice with callbacks before going deeper into their flaws. Consider this simple expression of a callback in an async fashion.

function mortalCombatGreet () {
    console.log('Choose your destiny')
}
setTimeout(mortalCombatGreet, 1000)

How is that working?

Functions in JavaScript are first-class citizens which basically means that they can do everything others can do. You can assign them to variables, pass as arguments, return from the functions. In the example above we pass our callback function to a built-in API, but it could be any other API or library. The description of this code would be: "create a timer with a callback, execute a callback in 1000ms". When dealing with callbacks, there is some code which will execute immediately, and some code which will be run later. We essentially divide our program into two parts - the first part is everything outside of a callback including setTimeout call, and the other one is our callback itself. There is a clear notion of "now" and "later".

More callbacks to the God of callbacks

Now let's consider an example that is a bit more sophisticated. We will try to read three files in a sequential order using callbacks. Assume that readFile function is some function that takes time to complete.

readFile('first file', function (firstFileContents) {
    console.log(firstFileContents)

    readFile('second file', function(secondFileContents) {
        console.log(secondFileContents)

        readFile('third file', function(thirdFileContents) {
            console.log(thirdFileContents)
        }
    })
})

Here we tried to express a temporal dependency using callbacks. Pretty straightforward and common async operation to use. We can clearly see that a second file read need to wait for a first read to finish. Same relationship exists between third and second reads.

Temporal dependency === nesting?

You could notice that an expression of each single temporal dependency is achieved through nesting callbacks inside of each other. And you could also imagine this going really big and crazy in some complex parts of application logic. This is often referred to as Callback Hell or Pyramid Of Doom in Javascript community (did you really think I attached that pyramid image by accident?). When it comes to this concept, people mostly complain about nesting and indentation. But is it all about how the code looks? I could immediately start proving you, that code formatting is not the fundamental problem of the callbacks.

function readFirst (cb) {
    readFile('first file', function (fileContents) {
       console.log(fileContents)
       cb()
    }) 
}

function readSecond (cb) {
    readFile('second file', function (fileContents) {
       console.log(fileContents)
       cb()
    })
}

function readThird () {
    readFile('third file', function (fileContents) {
       console.log(fileContents)
    })
}

readFirst(function () {
    readSecond(readThird)
})

This code definitely doesn't obviously suffer from identation and nesting problems, does it? This is what is often called as continuation passing style. We could go on with refactoring and eventually come up with something that would not look like a callback hell to an average javascript developer at all. This is where the most serious problem lies. This is where our understanding needs to be redefined, because this code is as susceptible to callback hell as previous one.

Inversion of control

Notable feature of callbacks is that the part of our code is executed by a third party. We can't exactly know when and how our code will be executed. When we loose control on our code and pass it to someone else, the Inversion Of Control happens. There are many definitions of the Inversion of Control term on the internet, but for our case that's pretty much it.

Trust issue

In our first example we passed our code to setTimeout utility. There is nothing wrong with it, right? We all use timers! Timer API is a well known and established feature. Nobody is thinking to themselves "oh, wait, maybe it will not execute my code right in time, or it will not even execute it at all". We can trust it. And that's the main point. What if we pass our callback to some external library that is not a part of standard API? What if, for example, we rely on something else to execute the code which charges our client's credit card?

fancyAsyncFunctionFromLibrary(function () {
     chargeCreditCard()
})

When you are passing callback you are trusting that it will be called:

not too many times
not too few times
not too early
not too late
with no lost context
with correct arguments

What happens if this trust falls apart? Can you really cover all of those cases with workarounds in all of the places where you use callbacks? I would assert to you, that if you have callbacks in your application and you don't have those cases covered, then your app potentially has as many bugs as there are callbacks in it.

Going natural

Without diving deep into the science, we can safely say that our brain is essentially single threaded. We can think about only one single thing at a time at our highest level of cognition. We also like to think about stuff in a sequential fashion. Take a look at how you are planning your day. You allocate your time for a single task and complete each of them sequentially one by one: take shower, have a breakfast, make a call to the boss, participate in a meeting, etc. But it often doesn't play that nice, does it? Usually, at least a couple of times, you will get interrupted. Your mom calls while you are on a meeting, delivery guy rings a door when you are trying to wrap your head around a bug. Thankfully, when this happens, you are not going like: "ok, that's awful, I am going to my bed and start tomorrow from scratch". From this perspective, our brain is a lot like a JavaScript engine. It can be interrupted with an event, choose to respond to it and then continue running.

Where the bugs happen

If that's how our brains work and how we handle tasks, we are most likely to code in the same way... naturally. But language engines, as well as JavaScript, often don't work the way that is immediately obvious to us. Every time you are not thinking about the code in a different way than a compiler, there is a potential bug in your program. Thankfully, we can both train ourselves to think more like a compiler and invent new patterns and syntax that both fit our mindsets and computer needs. That's why it is extremely important to understand how all of those patterns, frameworks and libraries work internally. And it is not enough to just know the API and a general definition.

Reasoning about callbacks

Remember me saying that the only way to handle temporal dependency using callbacks is through nesting? Consider the next pseudo code which will express how we would like to, at least in my opinion, reason about async operations:

start someBigOperation1
do stuff
pause

start someBigOperation2
do stuff
pause

resume someBigOperation1
do more stuff
pause

resume someBigOperation2
do more stuff
finish

resume someBigOperation1
do more stuff
finish

Would be great to have this sort of syntax to handle async operations in Javascript, huh? We are doing one step at a time, and our brain linearly progresses through the code. Doesn't look like callbacks at all... but what if it did?

start someBigOperation1
do stuff
pause
    resume someBigOperation1
    do more stuff
    pause
        resume someBigOperation1
        do more stuff
        finish

start someBigOperation2
do stuff
pause
    resume someBigOperation2
    do more stuff
    finish

Whether you are doing it with function expressions or with function calls, that doesn't matter. The code is not looking sequential anymore, you can't instantly figure out the order of operations and you are forced to jump all over the code to get the idea. The async flows in our apps can become really complex, and I doubt that there is a developer in your team who understands all of them from start to end. You can understand step one, two and three, but it quickly becomes a thing beyond our capacity as soon as it goes like this: "start step one, two and three, and as soon as step two is finished, cancel step three and retry step two, then start step four". God bless you if those steps are callbacks jumping around the files in your projects. This is the case when your brain is fundamentally unable to reason about the program anymore. Callbacks force us to express in a fashion that contradicts the way our brains are used to plan things. Callbacks alone don't have right tools to let us write sequentially looking async code. Seems like we need a better pattern.

What doesn't fix the problems

Multiple callbacks

readFile(function (fileContents) {
    console.log('Success! ', fileContents)
}, function (error) {
    console.log('Error! ', error)
})

There is way now for the utility to notify us about an error using a second callback. Looks good. But guess what? Now we are trusting the utility to execute two callbacks properly and basically you end up with 2x the number of potential bugs that you need to cover in your code. Ouch!

Error first style of callbacks

readFile(function (error, fileContents) {
    if (error) {
        console.log('Error! ', error)
    } else {
        console.log('Success! ', fileContents)
    }
})

Two callbacks are too crazy, so let's get back to just one. We are going to reserve the first parameter for an error. It definitely removes the concerns about calling two callbacks, but what happens if utility messes up the order of arguments? What if it calls callback twice - once with error, and then without it? What if it calls the callback both with error and success arguments? The same trust issues arise with couple of new ones. Still doesn't look like a solution at all.

Outro

You should now have a pretty good understanding of callbacks and be able to articulate about their drawbacks. It is clear that callbacks alone will not help you to solve each and every problem in your async code. Hopefully, next time when you hear about Callback Hell, you will be confident about what it truly means. It is about design limitations which can't be solved no matter how much you refactor your code. The Ideal Pattern should provide us an ability to write async code that looks like a synchronous one. That sounds fantastic, but it should be possible, right? There are still plenty of approaches to take a look at and in the next article we will talk about Thunks and see how they make asynchronous programming much easier.