Pros and cons of full websocket transport vs hybrid transport

[Momics]

I'm just curious about this. Was wondering what the (dis)advantages would be of going to a full websocket transport vs a hybrid one (e.g. with Apollo Server).

The application I am building is (mostly) real-time and the websocket is open anyway for all the subscriptions... What are the benefits of having mutations and queries still travel over HTTP instead of websockets?

[n1ru4l]

For query operations, you could leverage HTTP caching if you compile your GraphQL operations with single endpoints with tools such as https://wundergraph.com/

If you have public API users, that are not using Node.js, they are forced to search or re-implement the protocol in another language (though this would still apply for subscriptions), this is why some argue for public APIs SSE via HTTP (as supported by graphql-helix might be the more light-weight alternative, as the protocol implementation is not that complex. However, switching also has other implications such as the limit of maximum open connections inside a browser client environment and having to serve via HTTP/2, etc. (There is also this article, but it is a bit too aggressive IMHO)

If you have a monolithic-like app where query/mutations and subscription logic lie aside and you know that all the clients can use WebSockets and you have control over the whole stack from Node.js server to frontend client, I personally see no benefit in also setting up an HTTP endpoint.

I have seen multiple projects where WebSockets have been an issue, e.g. the load-balancer was not configured properly. This could become quite tedious if you do not have full control. That's why for some projects I wrote my own small GraphQL transport which uses Socket.io (can be found here). The benefit here is that it fallbacks to HTTP polling for executing the operations. However, I also assume that most people are just fine with graphql-ws, and I would recommend that.

[n1ru4l]

I guess that will only affect apollo-server users. TBH I think such stuff should not be tied to the server, but rather be implemented as an execution/schema middleware, so everyone can benefit from it...

[enisdenjo]

Great answer by @n1ru4l, I guess he covered pretty much everything. 😄

[97amarnathk]

So are there any upcoming clients for Go / Python / Java , utilising graphql-transport-ws as the underlying protocol ?

[enisdenjo]

I personally dont know any in Go and Python, but I remember @UglyHobbitFeet and @Blemicek mentioning using a Java backend implementing the graphql-transport-ws Protocol.

[enisdenjo]

Oh and, @Kingdutch working on a PHP implementation over at goalgorilla/graphql-php-ws.