Add support for the graphql-transport-ws GraphQL over WebSocket Protocol
See original GitHub issueCurrently our ASGI and AIOHTTP integrations only support the “legacy” graphql-ws
websocket subprotocol. Its repository states:
The subscriptions-transport-ws library is not being actively maintained. It is recommended that you use the graphql-ws library instead. For details read the GraphQL over WebSockets announcement.
Just for clarification: the legacy graphql-ws
websocket subprotocols library is called “subscriptions-transport-ws”, while the newer graphql-transport-ws
websocket subprotocols library is called “graphql-ws”. Yep, slightly confusing.
According to NPM download stats the legacy library is still downloaded more often than the new library. Since both protocols are incompatible I propose we support both for now and give users a choice to disable them individually.
I already implemented the new protocol for our AIOHTTP integration, which went very well since the new protocol is way better documented than the old one. I’m currently working on tests and a good abstraction that allows us to reuse the code for the ASGI integration. I’ll finish work on this next week.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:7 (7 by maintainers)
we use
graphql-transport-ws
in combination with starlette & django - works really nice. I’m not sure if supporting the old library/spec makes sense, because the backend code is so much different and there is not much in common.I think many downloads on the old library are coming from the very first tutorials with subscriptions (which ar quite popular). A good subscription example with the new protocol in the strawberry documentation would make much more sense IMO.
Thats a really interesting setup, thanks @Speedy1991