What about new features like a query batching and subscriptions

[auwtch]

https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07

[neelance]

Definitely interested! Is there any indication on when this will end up in the official specification or some other spec document?

[auwtch]

No, but Facebook uses these internally. The Apollo (client and server) also supports both features, the official GraphQL server supports only subscriptions.

[neelance]

Okay. I'm not against those features, but there are other things I need to take care of first. Effectively this means that those features will either be added when I need them myself or via PR.

[paralin]

I'd like to help implement these - maybe

In my project, I do a pipeline where I start out defining the schema in Protobuf, and it gets converted into a variety of different things (TypeScript definitions, GraphQL schema).

Right now I'm looking at an arms race, really:

• PlayLyfe - got my relatively large project working with some intermediate code-generation and interface manipulations (I generate a function to get the GraphQL schema type name for all of my ProtoBuf schemas). The code base is crap, though. I don't see adding subscriptions to that being a very easy thing.
• Go-Graphql - massive, seems well made, but pretty inactive and for some reason there is no documentation / any way to convert a schema AST into a Go schema. Supports subscriptions (!)
• This repo - nicely written, requires some intermediate code generation from me, but otherwise I like it more than the others. The main difficulty here is I have to do this stuff which I really hate. I can code-gen most of this, but it just seems like a mess. Some reflection could work better.

Either way, if we could support subscriptions in this repo I think I would probably adopt it for my projects. I'm going to try to write the code-gen stuff in my codebase to make everything work as-is with this repo. If I can do that, I'd love to help implement subscriptions.

[paralin]

I've ported all my stuff to run on this library now, nice! Requires a LOT of code generation to cover trivial member field struct resolvers, but it's worth it I think.

As for subscriptions, where are we on that? I can have a look at what would be required to add them in. Thoughts on what the API could look like @neelance ?

I'm thinking Exec( signature is the same, but it just doesn't return until the subscription terminates or the context terminates.

[neelance]

What documentation is out there on how subscriptions are supposed to work? How do the updates get pushed to the client? WebSockets?

[paralin]

Facebook seems to use all of these features internally, and just hasn't bothered to put it into the spec / OSS code yet.

Other related issues:

• Real-time / streaming / live query / RethinkDB support apollographql/apollo-server#34
• [meta] Support real-time updates via event subscriptions facebook/relay#541

Apollo says "we can work on it early march," not sure on relay.

[paralin]

Beginning to work on this now. I've moved my essays worth of notes from here to https://gist.github.com/paralin/f6891bd30eb96e91fba628096af3278c.

@neelance I've completed an extensive document at that Gist with my proposal for implementing these features. Feel free to let me know what you think! I'll have a go at prototyping these tomorrow morning on a flight.

[neelance]

Is it allowed to use @live and @stream everywhere? I'd expect that the schema would need to explicitly say where those modifiers are possible. In that case you could expect a different method signature for the resolver.

Imho the features are not yet properly specified. I'd rather wait for Relay 2 to be officially released. Relay 2 is supposed to have those features, so when they release it they will also have to add documentation or a spec and it will also be an official reference implementation, not just something that graphql-js happens to support.

Good luck with any experiments you want to do in a fork, I hope you can make it work for your use case. But please don't be disappointed if we can't bring it into this repo because it is too experimental.

[paralin]

That's fine! I know it's experimental.

Placing these specifiers on fields doesn't need a schema change, I think. For stream and defer, it should always work (stream on arrays or channels at least). For live, if we want to be aggressive we can poll the field for changes with a configurable rate. I don't think that's necessary, though. Just treat live like defer if there is no chan returned.

[bsr203]

FYI graphql/graphql-spec#267

https://dev-blog.apollodata.com/the-next-step-for-realtime-data-in-graphql-b564b72eb07b?gi=d976ae86986#.z9zgh76ip

[paralin]

FYI I've moved all of my work from this thread and rewritten everything into http://github.com/rgraphql/magellan

[mishudark]

I saw at graphql-go/graphql, and seems like they have a lot of pending PR, also the code has more boilerplate, I think the neelance has a better aproach

[LeeWong]

I also think that the neelance has a better aproach. Facebook modern relay is finally out and it supports graphQL subscriptions. I am wondering if this library would support graphQL subscriptions? Thanks.