Graphql-dotnet: Add a subscription example that uses websockets/signalr

[BhaskaranR]

[joemcbride]

No, there is not currently an example that uses those. The subscription type has been added fairly recently, so it should now be possible to add one.

[neooleg]

Hi @joemcbride, could you please update -- is there an example appeared?

[joemcbride]

@neooleg No, I am not aware of an example yet.

[neooleg]

Thanks for quick response.

I plan to deal with subscriptions, so will share my experiments, if it's useful here.

Related question -- is this possible to setup WebSocket connection (e.g. SignalR) and send everything thru it? I mean to use this WS only (w/o any HTTP endpoints) for queries, mutations as well as for subscriptions?

[joemcbride]

@neooleg Yes you can use the engine outside of a HTTP endpoint. The GraphQL engine does not rely on any specific transport, so you can use the DocumentExecuter and the DocumentWriter with a WebSocket connection.

[garethrampton]

@neooleg I'd be really interested in you seeing your experiments here - I've not found any examples of getting subscriptions working (with .NET).

I've got some ideas how this might work for us via SignalR (and we're already internally using an event driven architecture), but its just at concept stage right now.

[neooleg]

@garethrampton as far as I understood -- is this not a simple solution for SignalR and subscriptions in graphql-dotnet working together?

P.S. We're using HTTP until in development, so didn't have a change to set mentioned experiments. Could you please share more info (pitfalls, code or concepts), if possible?

[OneCyrus]

i'm interested to get a basic subscription with apollo client working as well. any starting point to get the schema right and how i should push data from the backend?

[neooleg]

@OneCyrus,

Personally, I didn't plan to use Apollo in this initiative -- SignalR and graphql-dotnet only.

However, if you will share anything with Apollo it will be interesting. Although, it might be out of scope for this thread, so sharing a link would be the best 😄

[joemcbride]

Just a note that the official spec does have info about how subscriptions should work now, so that should be implemented execution engine, which it currently isn't. http://facebook.github.io/graphql/#sec-Subscription

[neooleg]

@joemcbride thanks for sharing.

Is this means that subscriptions will be a part of graphql-dotnet, so they will be used without additional SignalR code?

[joemcbride]

@neooleg my first thought is that the underlying transport would be pluggable, so you would still need something like SignalR for it to work. The core engine would provide the behavior described in the spec though.

[OneCyrus]

@joemcbride i was searching this backend implementation in the source. but couldn't find it. is this something you're working on now?

[joemcbride]

@OneCyrus No, I am not currently working on it.

[neooleg]

@joemcbride sure, it absolutely make sense. My point was a bit different -- will graphql-dotnet do all job for developer on backend regarding pub/sub and further push (when a developer provides e.g. SignalR transport of it)?

Just to be aligned -- do you have an approximate ETA for the subscriptions scope?
Anyway, as soon as I will tackle a solution -- immediately will share this as promised above.

[lbrolinz]

@neooleg @joemcbride , Hi, is there any solution for graphql-dotnet subscriptions?

[joemcbride]

@lbrolinz This issue will be closed when there is. It is still Open.

[neooleg]

Disclaimer

Let me to update since I've spent some time for investigation. Probably the summary will be useful for someone, however, it's far from final goal of the topic.

Abstract

We're targeting .NET Core only, but SignlaR 2.0 (which compatible with Core) was rewritten from scratch, so released just a few days ago. It doesn't even have any documentation yet (https://github.com/aspnet/SignalR/issues/724). Hence, IMO it looks like a bit fresh and need to be settled few releases until take it to production.

Conclusion

Thus, it was decided to postpone implement solution with the graphql-dotnet subscriptions and SignalR 2.0 and kept a while subscriptions at all.

[joemcbride]

As a small update, #428 by @pekkah has a new SubscriptionExecutor which will provide a basis for subscriptions. Once that is merged, building an example with websockets should be fairly easy. 🎉

[pekkah]

I actually have a example ready also. Once I fix those small things with my PR I'll push it out.

[pekkah]

Example of using WebSockets with new ISubscriptionExecuter can be found here. Not production ready.

[diaconesq]

@joemcbride The link to the spec for subscriptions ( http://facebook.github.io/graphql/#sec-Subscription ) now redirects to http://facebook.github.io/graphql/October2016/ which doesn't seem to contain anything subscription-related. Do you happen to know where the subscription docs moved?

Update
The WayBackMachine has a snapshot:
https://web.archive.org/web/20170813042021/http://facebook.github.io/graphql/#sec-Subscription-Operation-Definitions

It seems like subscription-related stuff has methodically been removed from the last incarnation of the spec. Hmm...

[junelau]

It's still on the master spec.

https://github.com/facebook/graphql/blob/master/spec/Section%206%20--%20Execution.md