Support for GraphQL Subscriptions

[pixelsquared]

Is your feature request related to a problem? Please describe. I am working with an API that uses subscriptions and I would like to use them instead of polling.

Describe the solution you'd like I was thinking a function that returns a channel for the subscription?

Describe alternatives you've considered The alternative is polling

[benjaminjkraft]

Thanks for raising this!

I took a quick look at the Hasura fork of the shurcooL client, which seems to be the only Go client that supports subscriptions, as well as the transport spec and client implementation Apollo uses/recommends. It looks like it will be a decent amount of work; I think it should be very possible to fit into the genqlient model and some parts may be simpler but we'll definitely need someone who's excited to implement it to make it happen.

I think much of the work will simply be in writing the client code, which should be similar to what other clients do. We'll also need to figure out what it actually looks like to open/close a subscription with genqlient; presumably you pass a callback (with types we generate?) to the entrypoint function to open a subscription but there are some details to work out for what to do on error and how to close. My guess is wiring up the types there won't be too hard; it should just be like a query in terms of the types we generate, and it's the control flow that's very different.

Let me know if you are interested in taking a stab at that! (Or if anyone else reading this is.) I'm happy to provide any guidance you need for how to integrate with genqlient, or schedule a call to talk about it.

[pixelsquared]

I am interested in working on this. I am going to do some reading from the links you gave and look in to how genqlient works a bit more.

[gedw99]

what transport ? http polling, websockets, sse ???

[StevenACoffman]

There's also subscription support in the toy client in gqlgen https://github.com/99designs/gqlgen/blob/779d7cdd4991e3cf4bf1ecbdea1f02664a56ac8d/client/websocket.go#L28

[lander2k2]

@pixelsquared Have you begun working on this? I'm also interested in adding subscription support but don't want to if you already have something in the works...

[pixelsquared]

@lander2k2 I have been able to work on this yet. So go ahead.

[gedw99]

might be interested in how they used graphql and golang: https://github.com/borderlesshq/graphrpc

[lander2k2]

Have had to de-prioritize this :( May return to it later...

[jjauzion]

Hello all, is anyone working on this feature ?

[jjauzion]

@benjaminjkraft if no one is working on this, I'm willing to work on it :)

[jjauzion]

@benjaminjkraft is it ok to use external lib for the websocket ? like this one

[StevenACoffman]

https://github.com/99designs/gqlgen/blob/master/go.mod#L6 uses gorilla/websocket and that project is again being actively maintained, so using that seems fine.

@benjaminjkraft https://github.com/infiotinc/gqlgenc also supports websockets and the code may be easier to adapt as it also depends on github.com/99designs/gqlgen (v0.16)

[benjaminjkraft]

Seems reasonable, we definitely shouldn't write our own websockets client. Ideally we should make it so that the interface isn't tied to an implementation, so if users have a different lib they want to use, they'd just have to write the adapter. (Similar to how you could write your own Client currently; I don't know enough about subscriptions to suggest a specific API offhand.) Not strictly a requirement though.

[jjauzion]

@benjaminjkraft PR ready, it's my colleague @matthieu4294967296moineau who worked on it. We are contributing as a Company. License Agreement will be signed soon, I'm checking with my CEO who should sign.

PS: we love what you do at Khan Academy :) (our CEO actually followed some courses on your portal) so very happy to contribute

[simluk]

Hello all, just found this thread and was going through the PR. We are using query and mutation operations in our solution, but will need to implement subscriptions as well. @benjaminjkraft @jjauzion when do you plan to merge the PR ? We'd be happy to test it out :)

[benjaminjkraft]

Thanks for the poke! I just did another round of review on the PR. A review from anyone else with websocket experience would be useful; I don't have much so I have a lot of questions. Unfortunately it's hard for me to give a timeline -- this is a lot of new API surface so I do want to make sure we get it right. If you need to use websockets right now you could try using the version in the PR and let us know how it goes!

[simluk]

Thanks for the response @benjaminjkraft. I did start testing with the PR version. Will let you know how it goes.