Promises in Sails.js

[ajbraus]

I just started on Sails.js and besides associations the only other issue I've come up against that is a really pain is the "Pyramid of Doom" or "Callback Hell."

Is there any plan to integrate promises into Sails.js to avoid this?

I can imagine that a successful implementation of promises would create a very flat and delightful DSL.

[stefanpenner]

http://promisesaplus.com/implementations might lead to a good implementation that fits your use-case.

From a backend performance standpoint, https://github.com/petkaantonov/bluebird seems to be leading the pack.

(@petkaantonov , @domenic)

[mikermcneil]

We use async internally

[bmac]

@ajbraus Where would you like to see promises used in sails?

The good news is waterline, sails' ORM, currently returns promises from its query methods. The bad news is the promise it returns is not https://github.com/promises-aplus compliant and in practice I have not found it to be very useful.

[ajbraus]

I think I didn't really understand how to use the .then() command. That solves my problem! Thanks!

[bmac]

@ajbraus Take a look at the code that is being changed in this pr https://github.com/balderdashy/waterline/pull/191 It may give you a sense of some of the pitfalls that you can run into with waterline's promises.

[BlueHotDog]

I think this is a great idea, but if we're already incorporating BluebirdJS, from my experience the API is cleaner and better and the perfomance should be better too.

— Sent from Mailbox for iPhone

On Sun, Dec 15, 2013 at 8:43 PM, Brendan McLoughlin notifications@github.com wrote:

@ajbraus Take a look at the code that is being changed in this pr https://github.com/balderdashy/waterline/pull/191

It may give you a sense of some of the pitfalls that you can run into with waterline's promises.

Reply to this email directly or view it on GitHub: https://github.com/balderdashy/sails/issues/1186#issuecomment-30616544

[mattaylor]

+1 for bluebird

[particlebanana]

Hey guys there is a proposal to switch Waterline from Q to Bluebird. I'm not a user of promises so I'm opening this one up for a community vote.

See https://github.com/balderdashy/waterline/pull/238 and https://groups.google.com/forum/#!topic/sailsjs/SXInGJbiqBQ

It seems Q has a more active community but Bluebird is more performant. Honestly it doesn't matter to me so which ever one you guys want is fine by me.

[BlueHotDog]

Tried both of them, Aside of the performance consideration, which is a huge plus INHO, as a "low-level" should be as performant as possible. Bluebird API seems cleaner.

I dont think the "end-user" should really care, since the end result is almost the same, the only real difference is a better performance/mem usage.

On Mon, Feb 10, 2014 at 9:53 AM, Cody Stoltman notifications@github.comwrote:

Hey guys there is a proposal to switch Waterline from Q to Bluebird. I'm not a user of promises so I'm opening this one up for a community vote.

See balderdashy/waterline#238https://github.com/balderdashy/waterline/pull/238and https://groups.google.com/forum/#!topic/sailsjs/SXInGJbiqBQ

It seems Q has a more active community but Bluebird is more performant. Honestly it doesn't matter to me so which ever one you guys want is fine by me.

— Reply to this email directly or view it on GitHubhttps://github.com/balderdashy/sails/issues/1186#issuecomment-34660502 .

Danni Friedland +972-54-7764415

[JoshGlazebrook]

+1 for Bluebird.

[mikermcneil]

I'd like to see this become pluggable, if possible-- if only to reduce the weight of core (esp. since there is some interest in using Waterline on the client; see the browser branch). What are y'all's thoughts? Maybe we allow for an overridable toPromise function?

[BlueHotDog]

How about using native promises(coming as some part of ES6) should be in major browsers soon enough.

I think we should "promise" that we'll support the ES6 specified interface for promises, and on the client we should simply use the native if available, on the server size doesnt really matter.

But i think that providing a dependency injection of sorts might work, so, maybe you might initiate the object with a promises info? like

promisez = require('mySuperDuperLib')
waterline = require('waterline')({promisesLib:promisez})

and as long as the promisez lib implements the ES6 interface, all should work, we'll use that lib internally.

BTW, a good pattern(i think) is to simply support both. you could check and if no CB is passed, use promises, if you have a CB use both? i.e always return a promise, but you can also resolve the CB(if given)? BlueBird provides few helper functions to do that.

On Wed, Feb 19, 2014 at 5:35 AM, Mike McNeil notifications@github.comwrote:

I'd like to see this become pluggable, if possible-- if only to reduce the weight of core (esp. since there is some interest in using Waterline on the client; see the browser branch). What are y'all's thoughts? Maybe we allow for an overridable toPromise function?

— Reply to this email directly or view it on GitHubhttps://github.com/balderdashy/sails/issues/1186#issuecomment-35462835 .

Danni Friedland +972-54-7764415

[kievechua]

Is it possible for the core team to switch from Async to Bluebird? That will reduce the dependencies in the core.

[dustinbolton]

+1 es6 native or Bluebird.

[t3chnoboy]

+1 for native es6 promises. You can use something like this until they come out.

[mikermcneil]

@t3chnoboy @BlueHotDog @dustinbolton @kievechua support for swappable promises will definitely be after v0.10, but I think we're all philosophically on board with it. One of those swappable promise impls should def. be es6 promises.

[stefanpenner]

+1 for pluggable promise implementation, as various environments/code bases have specific requirements.

[dzcpy]

+1 for bluebird, it's significantly faster than Q and even faster than async. I've been trying to program with all 3 of them and so far bluebird is the best one. See how simple it is in bluebird when dealing with mixing parallel and sequential operations.

https://gist.github.com/andyhu/c0b3e2c262ad3a17ec3b

I can imagine how messy it would be in async. I've done a lot of work with async lately, it's pretty capable. But with bluebird, the code gets much cleaner and better structure.It also runs faster. With Q, it's probably 5-10 times slower and consumes much more memory. There are lots of performance benchmarks out there which clearly show bluebird outperforms nearly every other async libraries except native es6 generator (async is also slower, and costs more memory).

I can't wait to see bluebird will finally integrated with sails to replace Q and async

[wuct]

+1 for bluebird or pluggable implementation. Bluebird is not only faster, but also easier to use.

[luislobo]

Waterline switched from Q to Bluebird: check https://github.com/balderdashy/waterline/pull/487#event-171216102

[BlueHotDog]

COOL

On Sun, Sep 28, 2014 at 11:28 PM, Luis Lobo Borobia < notifications@github.com> wrote:

Waterline switched from Q to Bluebird: check balderdashy/waterline#487 (comment) https://github.com/balderdashy/waterline/pull/487#event-171216102

— Reply to this email directly or view it on GitHub https://github.com/balderdashy/sails/issues/1186#issuecomment-57098814.

Danni Friedland +972-54-7764415

[Lujaw]

Awesome..

[wuct]

Finally!

[arthur5005]

Yay for Bluebird in Waterline!!

[mikermcneil]

btw re pluggable promises, here's where that happens in WL2 if you're interested in contributing: https://github.com/mikermcneil/waterline2/blob/master/standalone/Deferred/Deferred.js#L58

[alexventuraio]

Actually, what's the best way to implement Promises in Sails.JS v0.11.3 or v0.11.4?

[Crusader4Christ]

return Model.findOne(pk).where(where)
  .then(matchingRecord => {
      if(!matchingRecord) throw new notFound(`No record found with the specified id:${pk}`);
      if (req && req._sails.hooks.pubsub && req.isSocket) {
        Model.subscribe(req, matchingRecord);
      }
      return matchingRecord;
  })

leads to "a promise was created in a handler but was not returned from it" How to solve?