Why use a separate websockets approach instead of Subscriptions?

[Dindaleon]

Hello,

I was wondering why you decided to implement your own websocket events instead of using async graphql subscriptions?

[bkonkle]

Hi! I did that because GraphQL Subscriptions are one-way, and WebSocket events are full-duplex. With a GraphQL Subscription I can receive events from the server via the open connection, but I can't send events to the server without opening a new http connection to send a mutation. This introduces a little overhead to both client and server to negotiate that new connection each time rather than reusing the one that is already established.

For use cases that send a lot of events - like drawing apps or detailed analytics tools that would stream mouse movements, multiplayer games that would stream character positions, collaboration apps that capture realtime input, etc. - this overhead would add up quickly and you would have to scale up your servers to handle significant load even with just a small amount of users. Full-duplex connections would avoid those issues and would typically scale more easily.

If your use case will be very receive-heavy and only occasionally send, though, then GraphQL Subscriptions would work just fine.