Better option

[hongbo-miao]

Today in JavaScript world, graphql-ws is better option than subscriptions-transport-ws.
Just FYI 🙂

[pavelnikolov]

Closing as not related

[dinvlad]

Could you please let us know if the new protocol could be supported by this library in the future?

I'm interested because there appear to be multiple issues and security implications with the old protocol (which the new one addresses): enisdenjo/graphql-ws#3. Some of these might be due to the old protocol's implementation on the JS side (and thus not really related), but I'm curious if any still apply to this Go library.

Additionally, for JS clients, it seems since the old library has been deprecated in favor of the new one, we cannot continue using it with this Go server implementation (although we can still use the bare-bones WebSocket communication, but that can be quite a bit less user-friendly). Are there any alternatives or workarounds?

[pavelnikolov]

@dinvlad, this library is 100% protocol agnostic. You could use it with any protocol you want. For the subscriptions this library uses golang channels. This means that it is up to you how to handle the communication with the client. Feel free to create a custom middleware that would upgrade HTTP connections to WebSocket protocol or any other protocol. This project is just a reference implementation with the WS + Go + graph-gophers/graphql-go.