Mutations over websocket is a bit of weird one, just like queries. Some servers and clients support them and other don't. And it's often not clear.

oh i didn't realise that. i see no reason why queries and mutations couldn't take place over any transport - http, websocket, channels etc

graphql is transport agnostic after all

websockets should give you lower latency, avoid duplication of authentication etc

but regardless of what should be, if you are telling me that some servers only support subs over websocket but that queries and mutations must go via http, then this might be something that re-graph should support

this is something i didn't realise and i've spent a long time trying to tell people their servers are wrong 😢

Yes, that's my opinion as well. But graphql-java and kotlin-graphql see it differently. The crazy thing is the mutation/query is excecuted but the result is never send to the client.. As far as I've seen usages of the appollo client it also seems to use websockets just for subscriptions.

It took me some time what was going wrong when trying out those server libraries as well. It would be great if in time there was a better spec for graphql over websockets, and with that some tools to test server implementations.

I think re-graph does it right, for those other servers I could easily change the code to support multiple endpoints. The guild is also trying to get ownership of the code that contains the Protocol most use.

It's also pretty easy, to make it work with queries and mutations. Micronaut-graphql does support queries and mutations over websockets.

The GraphQL spec says virtually nothing about subscriptions, it seems like the defacto standard is Apollo because they do things first

It would be a small change in re-graph to add an option to specify which messages go over which transport

Yes, it would be a nice improvement.