graphql/graphql-js

Observables instead of Promises

DxCx opened this issue · 9 comments

DxCx commented

Hi guys,

As more I'm thinking about it the more i think it should be done,
So before I'm submitting a PR i would like to hear your thoughts about it.

So basically i want to add support for Observables (RxJs? Any other preferred library?) so resolver function will be able to return Observables as well (Observable | Promise | any)

Then create another execute function that will return Observable while chaining the original execute to call it with Observable.toPromise() function.

This way GraphQLResult can be reactive and this can be really useful for subscriptions and later in the future @live \ @stream \ @defer directives..

For the initial implementation I'm planing to always take(1).. later make it fully reactive..

So, what do you think?

davidyaha commented

I think @defer and @stream could also benefit from observables.

It will allow us to use the sweet power of observables in the server as well as the client.
Excellent proposition @DxCx!

  • 👍1
ohadgk commented

Amazing idea. I think it will open a door for far better architecture and maintainability.
Further more observables natural for reactivity or pub/sub and they are by far the best way I currently know to manipulate data.

  • 👍1
DxCx commented

Was just able to confirm that my idea works pretty well with subscription. (on unit test)
However the idea is simple:

  1. graphqlReactive should be used instead of graphql
  2. an hot Observable (Or subject) is being saved in context object.
  3. subscription resolver is being triggered when subscription doc is sent.
    • subscription resolver should return the hot observable from context mixed with any operator
      that is needed because of arguments.
  4. graphqlReactive returns an observable of GraphQLResult which is updated for each change.
leebyron commented

Closing this issue. Observables are exciting but do not yet have clear behavior relative to the GraphQL spec. Since this repository stands to be a production server and reference implementation, I don't think it's the right place to experiment with this.

I'm looking forward to seeing this sort of experimentation happen in additional libraries that don't need to rely on spec compliance. See more comments on this in #502.

Also just a note that the versions of @defer and @stream I've prototyped in Facebook's server have not required Observable, so we should be able to still pursue those ideas without this approach.

  • 🎉1
DxCx commented

for everyone that is interested in this,
I've just release graphql-rxjs package which adds Observable support to graphql engine:
https://www.npmjs.com/package/graphql-rxjs
Enjoy 👍

  • 👍13
  • 😄1
corysimmons commented

lol thanks @DxCx 👏

shtse8 commented

@DxCx Can we use it in the production?

DxCx commented

hey @shtse8,
original graphql tests are passing, i've played with it with couple of scenerios and made some PoCs and it looks like it works well..
however, it's not running on any major production environments..
you are welcome to give it a try, i'll try to support as much as i can..

  • 👍2
shtse8 commented

@DxCx Thanks! I want to give it a try as I really want to use @live directive for live data.