Skip to main content
  1. Posts/

Keep your promises with Bluebird

·1455 words·7 mins·
Dev Node.js
Table of Contents

Bluebird is a promise library I’ve used for almost every project. I remember when I was learning promise a few years ago, it took me a while to understand it.

One day, I was searching for some related materials, I found Bluebird. I was wondering what’s the reason for using a third party library when Node.js already has native Promise support at that point? Well, it turns out there are plenty. Although some of its features can be achieved with today’s Node.js, bluebird still can give you a lot of benefits.

Performance
#

Performance is one of the reasons I choose Bluebird at the very beginning. It’s very performant since…forever?

However, thanks to V8, Node 10 can now provide faster promise performance as well.

The following are the benchmark results on my laptop. You can try it yourself:

$ git clone https://github.com/petkaantonov/bluebird/
$ nvs use <node_version> # or nvm if you like
$ ./bench doxbee # or ./bench parallel depends on what you want to test

Node 10.16.0 doxbee
#

file                                       time(ms)  memory(MB)
callbacks-baseline.js                           132       24.89
callbacks-suguru03-neo-async-waterfall.js       159       40.16
callbacks-caolan-async-waterfall.js             203       45.71
promises-bluebird-generator.js                  211       35.49
promises-bluebird.js                            245       45.41
promises-cujojs-when.js                         306       61.96
generators-tj-co.js                             323       60.97
promises-lvivski-davy.js                        389       85.11
promises-native-async-await.js                  405       67.00
promises-then-promise.js                        444       68.84
promises-calvinmetcalf-lie.js                   489      125.57
promises-tildeio-rsvp.js                        538       77.93
promises-dfilatov-vow.js                        560      128.28
promises-ecmascript6-native.js                  594       79.71
streamline-generators.js                        799       89.75
observables-pozadi-kefir.js                     856      155.93
promises-obvious-kew.js                         882      107.42
promises-medikoo-deferred.js                    900      136.11
streamline-callbacks.js                        1350      106.45
observables-Reactive-Extensions-RxJS.js        1357      226.14
observables-caolan-highland.js                 3467      473.56
promises-kriskowal-q.js                        5242      289.95
observables-baconjs-bacon.js.js                5811      551.76

Platform info:
Darwin 18.6.0 x64
Node.JS 10.16.0
V8 6.8.275.32-node.52
Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz × 4

Node 10.16.0 Parallel
#

file                                      time(ms)  memory(MB)
callbacks-baseline.js                          290       84.93
callbacks-suguru03-neo-async-parallel.js       361       84.98
callbacks-caolan-async-parallel.js             450      113.71
promises-bluebird.js                           454      104.64
promises-bluebird-generator.js                 480       97.86
promises-lvivski-davy.js                       578      159.97
promises-cujojs-when.js                        668      170.84
generators-tj-co.js                            998      240.93
promises-native-async-await.js                1030      231.30
promises-ecmascript6-native.js                1072      223.22
promises-tildeio-rsvp.js                      1282      329.29
promises-then-promise.js                      1373      288.88
promises-medikoo-deferred.js                  1643      357.35
promises-calvinmetcalf-lie.js                 1924      371.12
promises-dfilatov-vow.js                      2483      535.41
promises-obvious-kew.js                       3352      552.88
streamline-generators.js                      6911      780.16
streamline-callbacks.js                      11767     1134.09

Platform info:
Darwin 18.6.0 x64
Node.JS 10.16.0
V8 6.8.275.32-node.52
Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz × 4

Useful APIs
#

.map, Promise.map
#

Promise.map is something like Promise.all but more concise and has the capability of currency control.

Let’s take a look at the examples:

const Promise = require("bluebird");

const getNameAfter5Seconds = name => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve(`Name: ${name} (${new Date})`)
    }, 5 * 1000);
  });
};

(async () => {
  const names = [ "John Doe", "Jane Doe", "Anonymous" ];
  const tasks = names.map(getNameAfter5Seconds);
  const results = await Promise.all(tasks);
  results.forEach(r => console.log(r));
})();

And the output will be:

Name: John Doe (Sun Jul 21 2019 17:04:37 GMT+0800 (GMT+08:00))
Name: Jane Doe (Sun Jul 21 2019 17:04:37 GMT+0800 (GMT+08:00))
Name: Anonymous (Sun Jul 21 2019 17:04:37 GMT+0800 (GMT+08:00))

You see, normally when we use Promise.all we would need an array of promises first. It’s not painful but still an extra step. With Promise.map you can achieve the same by:

(async () => {
  const names = [ "John Doe", "Jane Doe", "Anonymous" ];
  const results = await Promise.map(names, getNameAfter5Seconds);
  results.forEach(r => console.log(r));
})();

Additionally, you can even chain it:

(async () => {
  const names = [ "John Doe", "Jane Doe", "Anonymous" ];
  return Promise.map(names, getNameAfter5Seconds) // or use Promise.all here
    .map(r => {
      console.log(r);
      return r;
    })
})();

By chaining this you are just using the previously resolved results as input of Promise.map.

Last, let’s take a look at the currency control of Promise.map, which can’t be achieved with Promise.all.

It’s very straightforward, that means there won’t be more than the number of promises you specified running at the same time.

(async () => {
  const names = [ "John Doe", "Jane Doe", "Anonymous" ];
  return Promise.map(names, getNameAfter5Seconds, { concurrency: 2 })
    .map(r => {
      console.log(r);
      return r;
    })
})();

And the output is, yes, just like you expected:

Name: John Doe (Sun Jul 21 2019 17:20:04 GMT+0800 (GMT+08:00))
Name: Jane Doe (Sun Jul 21 2019 17:20:04 GMT+0800 (GMT+08:00))
Name: Anonymous (Sun Jul 21 2019 17:20:09 GMT+0800 (GMT+08:00))

It’s useful when you are doing something that might go wrong if the speed is too fast, like sending a bunch of HTTP requests. You can also combine this with a rate limit mechanism to properly manage your speed control.

.tap
#

When we looked at this example:

(async () => {
  const names = [ "John Doe", "Jane Doe", "Anonymous" ];
  return Promise.map(names, getNameAfter5Seconds, { concurrency: 2 })
    .map(r => {
      console.log(r);
      return r;
    })
})();

Don’t you think it’s really redundant to just print something?

Yes, apparently everyone thinks so. What if we want to take a look what’ was returned without taking the risk of forgetting to pass it back?

Promise.resolve(1000)
  .then(n => console.log(`The value is: ${n}`)); // We didn't return anything!
  .then(number => console.log(`I got: ${number}`)); // number is now undefined

That’s where .tap can be useful. We can literally “tap” on the promise without worrying about forgetting to return value.

Promise.resolve(1000)
  .tap(n => console.log(`The value is: ${n}`)); // We didn't return anything!
  .then(number => console.log(`I got: ${number}`)); // number is 1000

You might wonder, what if we return something else in the .tap’s callback?

Promise.resolve(1000)
  .tap(() => 2000)
  .then(number => console.log(`I got: ${number}`)); // number is still 1000

Of course, you can do anything shady with .tap if you like. But most of the time you might just want to print something, you can use a simple technique like:

Promise.resolve(1000)
  .then(n => console.log(n) || n)
  .then(number => console.log(`I got: ${number}`)); // number is still 1000

Or, just use VSCode’s logpoint?

.call
#

We often deal with objects with one-liners, like:

Promise.resolve([ 1, 2 ,3 ,4 ,5 ])
  .then(arr => arr.sort((a, b) => b - a));

While can be done with:

Promise.resolve([ 1, 2 ,3 ,4 ,5 ])
  .call("sort", (a, b) => b - a);

For more examples, see .call.

.reflect
#

When we do something to a collection, we need to make sure when some of them got rejected, the remaining promises won’t be affected.

const Promise = require("bluebird");

const rejectOnEven = number => new Promise((resolve, reject) => {
  return number % 2 !== 0? resolve(number) : reject(`${number} is rejected because it's even`);
});

(async () => {
  const tasks = [ 1, 2, 3 ,4 ].map(rejectOnEven);
  const results = await Promise.all(tasks);
  console.log(results);
})()

And the output will be:

(node:66335) UnhandledPromiseRejectionWarning: 2
(node:66335) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:66335) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

As you expected, the remaining promises won’t have the chance to finish. Of course, we can handle it in the rejectOnEven function, but can we deal with these later, and just let all promises settled?

If you are using Q, there is an .allSettled for you.

As for bluebird, we have .reflect.

Let’s modify the example:

(async () => {
  const tasks = [ 1, 2, 3 ,4 ].map(rejectOnEven);
  const results = await Promise.all(tasks.map(t => t.reflect()));
  results.forEach(r => {
    if (r.isFulfilled()) {
      console.log(`Resolved value: ${r.value()}`);
    } else {
      console.log(`Rejected reason: ${r.reason()}`);
    }
  })
})();

And the output:

Resolved value: 1
Rejected reason: 2 is rejected because it's even
Resolved value: 3
Rejected reason: 4 is rejected because it's even

One thing to notice is, it seems you can’t replace the Promise.all here with Promise.map.

…and others
#

The examples above are just something I used frequently. There are more. I believe you will find others useful as well.

Promisify, PromisifyAll
#

When your dependencies are still using callback style, you can easily transform it to promise-based style For example:

const Promise = require("bluebird");
const fs = Promise.promisifyAll(require("fs"));

Then you have something like fs.readFileAsync, fs.writeFileAsync now! You can also change the Async postfix if you are not satisfied.

You can then change your code from

fs.readFile("/path/to/somefile", (err, data) => {
  // ...
})

to:

fs.readFileAsync("/path/to/somefile")
  .then(/*...*/)
  .catch(/*...*/)

//or
try {
  const data = await fs.readFileAsync("/path/to/somefile");
  // ...
} catch (e) {
  // ...
}

If you are using Node version >= 8, you can have promisify from core module util. See util.promisify.

Developer-friendly
#

How is bluebird more developer-friendly than others? To explain this, I strongly encourage you to read this excellent blog post: We have a problem with promises.

Plug into other libraries
#

AWS SDK
#

const AWS = require("aws-sdk");
const Promise = require("bluebird");
AWS.config.setPromisesDependency(Promise);

IOREDIS
#

const Redis = require("ioredis");
const Promise = require("bluebird");
Redis.Promise = Promise;

In-place Q replacement
#

If you are using Q 1.x as promise library and still want to give bluebird a try, check bluebird-q.

W.T. Chang
Author
W.T. Chang

Related

Notes: Kinesis Agent for Windows
·425 words·2 mins
Dev AWS
Passed AWS Certified Developer - Associate
·407 words·2 mins
Dev AWS Certifications