Closed robertsLando closed 2 years ago
Because already in Nodejs 4.x basic support for promises was build in I am not a fan of additional libraries. Perfroamcne is not the real issue with this library (because mainly driver by the time the communication needs at all).
Because, as also said, I'm not that deep into Promises currently, but want to do an educated decision I invided a friend to this issue to provide his opinion/thouths on the topic ... SHould be more educated then mine :-)
I'm really looking forward that we will find a good solution
Sounds good! :smile:
I agree with @Apollon77. I wouldn't rely on external libraries for something that is natively supported in a framework - except if its broken in some way. Native promises are supported in NodeJS 4+, which should be the absolute minimum, considering that it's being discontinued right now. Native support also means no additional dependency that can break. I don't think the performance benefits mentioned in the linked article really matter. Usually a promise spends more time waiting on something than in its own implementation.
Also, NodeJS 8+ has the utility function promisify
, so you can just take callback-style functions and make promise versions from them until the function is written in promise-style.
Until that is the minimum version or for callbacks without the error argument, you could use the two helpers I defined here.
willbe done in next version
To promisify 'callback functions' we could use something like this:
About what type of promises to use, I see most package go for bluebird promises instead of native promises. We could decide what is better based on this: https://pub.clevertech.biz/native-javascript-promises-vs-bluebird-9e58611be22
Summary: It tells that third party promises are more performant than native but this lib is your so you should decide