Meteor, Apollo, and the @live directive

jamiter · December 16, 2017, 10:31am

@moberegger, thanks for starting this thread. It’s good to have a centralised place to talk about this specific topic. I’m very interested in this myself and done some research on the current state of the @live directive. Although I think Meteor is up for the task, there is a lot of work to be done in other areas.

Keeping close to the mainstream libraries

There is always a way to implement it ourselves, but personally, I would like to see support build in standard libs. The example repository using Meteor with RxJS is a great initiative. But if we want people to actually start using it, we want to keep close to the spec and mainstream libs. I’ll go into more detail about this later.

So what needs to be done to support @live for everyone?

Apollo Client doesn’t support @live yet
graphqljs doesn’t support multiple results from a query yet (Observables)

See this thread for the current state of support in Apollo Client 2:

github.com/apollographql/apollo-client

Add experimental support for @defer, @stream, and @live

opened 09:58PM - 09 Jan 17 UTC

closed 05:44PM - 27 Jul 18 UTC

paralin

I've just completed implementation of the three new directives mentioned in the …GraphQL Futures talk in GraphQL-Go: https://gist.github.com/paralin/f6891bd30eb96e91fba628096af3278c I now need to enable Apollo-Client to understand these responses. - A "query" now has a stream of responses (like a subscription) and will need a new NetworkInterface type to enable this kind of streaming transport. - The "query" ends when the remote server closes the result channel. It's up to the network interface to understand when this happens and communicate it back to Apollo. - Any query, even ones that do not use `@stream`, `@defer`, or `@live` can be sent over a streaming channel in the same way. If a query does not require returning data at a later time, the server will just immediately close the channel after returning the initial result. - Initial result looks identical to how Apollo currently receives results, with the exception of the lack of fields that are deferred in the initial response (those come in later) - The field path looks like `["regions", 0, "status"]` and comes in in `extensions.path`. These features are obviously experimental, but I've been able to build a real proof of concept of the server end of this in just a couple of days. I'm interested to now get it working properly with Apollo.

This is on the roadmap for the Apollo Server:
https://github.com/apollographql/apollo-server/blob/master/ROADMAP.md#support-for-defer-live-and-stream

Talking about the need for Observables in graphqljs.

Currently working example of Meteor and @live

I also think this is the example repo he talks about:

There are some issues though:

Doesn’t work with Apollo 2. See for example this issue.
Doesn’t seem to be aware of the proposed patch syntax. ({ path: [ 'author', 'posts', 0 ], data: { title: 'Hello', views: 10 } })
It uses RxJS (meteor-rxjs), which is very good lib, but we might get away with using plain Observables.
Uses own GraphQL-RxJS, which is nice, but not standard.

Other interesting issues/discussions

Lee Byron, one of the authors of GraphQL, is saying you don’t need observables, but doesn’t give a hint about an alternative:

github.com/graphql/graphql-js

Observables instead of Promises

opened 03:46PM - 23 Sep 16 UTC

closed 11:21PM - 15 Nov 16 UTC

DxCx

Hi guys, As more I'm thinking about it the more i think it should be done, So b…efore 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<any> | Promise<any> | any) Then create another execute function that will return Observable<GraphQLResult> 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?

Grapher

Grapher is also a great peace of software. @diaconutheodor did a great job here and explains some of the pain points of GraphQL in this post:

I believe though, also after the video you shared, that these issues will get addressed in the future and with help from the community, we can make GraphQL (almost) as easy to setup as Meteor, including support for @live queries. In the meantime, for people who can’t wait for that, Grapher is a nice alternative. But again, not as widely supported as GraphQL.

Next steps

I believe the focus should be on getting @live support into Apollo and GraphQL itself and work from there. Connecting Meteor afterwards, probably using Observables, should be a walk in the park (which it never turns out to be, but let’s stay positive here ).