-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add graphql-ws support in light of subscriptions-transport-ws deprecation #1022
Comments
@bglw thanks. We have plans to support both versions for the next major release. |
@tyranron this feature is landed? :) was thinking that maybe I can be a good mentee? because I would like to have this feature |
@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. |
lets see if I can put in my todo list :) there is any channel that can make easy the onboarding on the package? |
@vincenzopalazzo just ask directly in the related PR. |
Is juniper using However, I receive |
@LegendL3n I think the new protocol graphql-ws is still not supported, I was planning to add it in the next few months |
Indeed.. Just saw on the README, that example really confused me 😅 |
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 |
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:
|
- consider `juniper_graphql_transport_ws` crate on CI - implement auto-selection of protocol in `juniper_warp` crate - support `graphql-transport-ws` protocol in `juniper_actix` crate - implement auto-selection of protocol in `juniper_actix` crate Additionally: - move `examples/warp_subscriptions` into `juniper_warp/examples/subscription.rs` - move `examples/actix_subscriptions` into `juniper_actix/examples/subscription.rs` - move `examples/basic_subscriptions` into `juniper_subscriptions/examples/basic.rs` - bump up MSRV of `juniper_actix` crate to 1.68
Hi it looks like this was merged but I don't see the crate showing up on crates.io. Is there a plan for when it will be released? |
@chris-pattern yup, almost there: |
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.
The text was updated successfully, but these errors were encountered: