Graphql-go: What about new features like a query batching and subscriptions

[blasterpistol]

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?

[blasterpistol]

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:

• https://github.com/apollostack/graphql-server/issues/34
• https://github.com/facebook/relay/issues/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 https://github.com/facebook/graphql/pull/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.

[lpalmes]

I've been looking at relay-modern and they don't have documentation yet for how subscriptions should work, it should be possible to follow apollo idea which i believe it should work with relay out of the box.

[LeeWong]

@lpalmes Any update on your latest experience with relay-modern on subscriptions? Thanks.

[neelance]

I'm still waiting for an update to the spec.

[mikeifomin]

@neelance https://github.com/facebook/graphql/blob/master/rfcs/Subscriptions.md

[mikeifomin]

But I guess neelance is waiting updates on this page https://facebook.github.io/graphql/

[lpalmes]

@LeeWong i'm sorry i've missed the notification, i'm having way too many github notifications, my bad. I have to try subscriptions in relay-modern and is something that just now has been added to the docs.

@neelance The spec has been updated and now it has subscriptions by this pull request and it has been implemented in graphql-js, to have a reference implementation.

[LeeWong]

@lpalmes Thanks. Very excited to see how the relay-modern could work well with this graphql-go, especially in the subscriptions.

[tonyghita]

Subscriptions have been merged into the specification: https://facebook.github.io/graphql/#sec-Subscription

I've started reading through... let's do this!

[tonyghita]

FWIW I've implemented query batching on top of this library. Works great with the Apollo client!

[sdemontfort]

Hey @tonyghita, how did you go about implementing query batching on top of this library? Could you show me an example?

[nicksrandall]

@sdemontfort Here is an example of implementing batched queries. https://github.com/nicksrandall/batched-graphql-handler

[tonyghita]

@sdemontfort I've been a bit short on time, but I'm planning on making an example repo like @nicksrandall to give a different approach.

The idea is more or less the same though.

[ijsnow]

Hi all! Are you happy with your decision to go with this library rather than https://github.com/graphql-go/graphql? From what I've gathered, this project is cleaner yet less complete in comparison and is more actively maintained. That could either be a result of it being less complete or a good sign of ongoing development.

I'm just trying to decide on which route I should take when starting to use graphql in a go project I'm starting soon. I asked a similar question over there https://github.com/graphql-go/graphql/issues/196#issuecomment-311431814

Thanks!

[ijsnow]

I like the API of this project a lot more. It's so much cleaner. I think I'll go with this one. I went through both star wars examples for the repos and based my decision on the number of questions I had on each and how hard they were to figure out. Although this project's example had a couple hundred more lines of code and no documentation, I could much more easily understand what was going on and trace it through the library.

[ijsnow]

I'll do my best to help this repo move forward in the future as well. I may start contributing by writing documentation :P

[neelance]

@ijsnow I'm happy to hear that you like the project. As a heads-up: The API will get a major change soon, see #88.

[mikeifomin]

No news about the subscription?

[juliandroid]

I saw that 6 months ago, some part of the "subscription" support was done, but no tests and probably the most important part is not there yet. Any feedback?

[mikeifomin]

@juliandroid did you mean that the package can parse a subscription keyword?
https://github.com/neelance/graphql-go/search?utf8=%E2%9C%93&q=subscription&type=

Does anyone need GraphQL subscriptions right now? We can discuss a implementation.

[juliandroid]

@mikeifomin what are the alternatives? If you want to keep track of some property/data and fetch the update?
Ideally, Apollo Client + Websocket + Subscription

[mikeifomin]

@juliandroid I already use the Apollo in my node.js stack.
But one of my project requires the golang-graphql backend and some live data features.
For now I have implemented the live data in a pure websocket + custom events + json. This cause
the invention of a wheel at the frontend.
I'm looking for more convenient and robust solution like the Apollo server for golang.

[juliandroid]

Basically, that means Apollo server (handler for graphql-go), plus subscription support. The only thing that I've found so far was github.com/nicksrandall/batched-graphql-handler that handles batching part.

[paralin]

Rgraphql should do what you want, and we will be doing stability passes on it in the coming week. It's a very different approach but in the long run I think it will win out. The binary encoding and compression is too good to pass up.

[juliandroid]

@paralin Correct me if I'm wrong, but Rgraphql requires graphql-go (the other one) and also Rgraphql from clients side doesn't support iOS and Android as it is the case with Apollo :(

[andrewshvv]

Hey @neelance! Thanks for the library! Have re-written my API using it, but was initially mislead that it supports subscriptions, mostly because of grep returned some result by keyword subscription 😄 . Is it in your near plans to implement it?

[smithaitufe]

I need graphql subscriptions as well

[kivutar]

There is an implementation here https://medium.com/functional-foundry/building-graphql-servers-with-subscriptions-in-go-2a60f11dc9f5

[matiasanaya]

@pavelnikolov think we can close this one? Subscriptions is now supported and an alternative implementation of query batching has been posted by @nicksrandall.