Add graphql-ws support in light of subscriptions-transport-ws deprecation

[bglw]

This was mentioned in #896 but declined at that point. Since then, however, the winds of change have blown in favor of graphql-ws. The graphql-ws protocol differs from Apollo's original subscriptions-transport-ws protocol, and Apollo are soon to archive their protocol and are now recommending use of graphql-ws.

There is already some friction, as graphql-ws-client (and most ws clients coming out) only support the new protocol, while juniper only supports the old.

[tyranron]

@bglw thanks. We have plans to support both versions for the next major release.

[vincenzopalazzo]

@tyranron this feature is landed? :) was thinking that maybe I can be a good mentee? because I would like to have this feature

[tyranron]

@vincenzopalazzo nope, haven't touched it yet. Would like to see a PR from you, if you're willing to. As for design, I think it should be feature-gated in the existing crate. Thanks.

[vincenzopalazzo]

lets see if I can put in my todo list :) there is any channel that can make easy the onboarding on the package?

[tyranron]

@vincenzopalazzo just ask directly in the related PR.

[davidgomesdev]

Is juniper using graphql-ws? I saw this workaround that came from this PR, so I thought juniper was already in graphql-ws.

However, I receive {"type":"ka"} messages, which isn't from that protocol AFAIK.

[vincenzopalazzo]

@LegendL3n I think the new protocol graphql-ws is still not supported, I was planning to add it in the next few months

[davidgomesdev]

Indeed.. Just saw on the README, that example really confused me 😅

[ccbrown]

I recently implemented the new protocol for another Go library, and could knock it out pretty quick here. It's fundamentally the same, but with some slight name changes and pings instead of keep-alives.

The worst part of it is just the naming of the protocol and libraries. The old protocol used the "graphql-ws" WebSocket subprotocol. Now, confusingly, the new protocol's reference implementation is a library called "graphql-ws". But it uses the "graphql-transport-ws" subprotocol. So I think the least confusing way to go about this is to forget about what the reference implementation is called, and organize based on the subprotocol name here.

So the new implementation can go into a new crate named juniper_graphql_transport_ws. And then in request routing, users can serve WebSocket requests using either the old juniper_graphql_ws or the new juniper_graphql_transport_ws crates based on subprotocol negotiation.

[allen-pattern]

Hello, is there any update here? Anything we can do to help see this feature rolled out?

[ccbrown]

Hello, is there any update here? Anything we can do to help see this feature rolled out?

@allen-pattern There's an implementation in the pull request here: #1158

If you'd like to help, you can:

• Leave comments on the PR. Does the PR meet your needs? Any thoughts on the API / crate changes?
• Give the PR a try and let us know how it works for you.