So, yes, I could imagine supporting queries and mutations that way, but I haven't kept familiar with the Apollo approach, and there's the question of how to manage the conversation; as in, with a resolver, rather than a streamer, will likely want to send a single response to the client.

The details of query and mutation over websocket seem to be in the spec https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md#connected-phase. It looks like the client sends gql_start and the server responds with gql_data followed by gql_stop. gql_start seems to not be specific to subscriptions. Regarding execution, it could use the normal functionality. The only changes needed for resolvers is that they might need to look in connection params for auth info instead of HTTP headers.

I think lacinia-pedestal already does support this, we are using it currently

That's how I wrote re-graph, and I was surprised to learn that most graphql servers don't support it, because it seems like such an easy thing to do

You just send start with a query (instead of subscription) and lacinia responds with one response and stops, see https://github.com/oliyh/re-graph/blob/master/src/re_graph/core.cljc#L73

Exactly as described in your link @domkm

@oliy Cool! I assumed otherwise because the docs say "Subscriptions are processed on a second endpoint; normal requests continue to be sent to /api, but subscription requests must use /ws". Glad to hear otherwise. Thanks.

:)

It's funny for me to learn something about Lacinia; I don't know/remember if it is intentional or not that you can perform queries in the subscriptions web socket!

Most don't, but micronaut-graphql does, Exactly because it's easy. The library with the protocol might move to the guild. Also aws has a protocol with some additions, like a subscription ack.

I'll check to see if I left some tests behind.

Most like kotlin-graphql, just implement the subscription part of the protocol.