Let’s talk about NodeJS Promises, I promise it wont’ be long

Let’s talk about NodeJS Promises, I promise it won’t be long

Serverless architectures are becoming very popular nowadays and NodeJS runtime is an interesting option on AWS Lambda. However, an asynchronous runtime is not always a suitable solution. So, understanding promises in JavaScript is essential to determine when to use NodeJS Lambda Functions on AWS.

In this article, we are going to wall through the characteristics of javascript in chronological order. As the title says, it won’t be long so bear with me!

🙂

First things first, non-blocking

It is a huge topic and can be considered a subject for another article. However is essential to keep in mind that NodeJS is a non-blocking language and uses a single Thread to run your operations.

What do you expect before running this snippet NodeJS code? Most people would expect something like this:

But, remember that NodeJS is asynchronous by default so the result of this code is going to be this:

Please notice that everything happens at the same time, go ahead and execute this code in your terminal, start to play around. You will start to understand what happens under the hood or optionally you can stay tuned a new article about Single Thread in details is coming soon. 👍

Callbacks are like promises’ ancestors

So, we had Callbacks before that are the foundation of NodeJS, using it you have the feeling that things are happening in sequence.

A callback is a function called at the completion of a given task, this prevents any blocking, and allows other code to be run in the meantime.

To illustrate callbacks let’s use the following example creating “doWorkCallback” function. This function simply waits 2 seconds and return either an error message or an array, so you can run in your terminal and alternate the return to see both results displayed in your display.

If you are not familiar with this ES6 syntax, using arrow functions. I also created this snippet with a simpler code with the same functions:

Here we can clearly see that the “synchronous” feeling is generated by the callback that is the functions passed to our myFunction as an argument.

🤯

Let’s go to the official definition of promise

The Promise object represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.

When you have an asynchronous runtime by default, fetching operations will eventually require you to know the result of an operation to determine the next events in your application or script. It is one example where using promise is a suitable approach, so let’s move forward and investigate its origins.

This need for knowing the result of an asynchronous operation is not new and has appeared since the beginning. They are designed to manage asynchronous code, like callbacks enhancement.

Here is an example: