Support subprotocol graphql-transport-ws

[gabrielsson]

As described in #811 and outlined really nicely by GavinRay97 in the comments beeing able to consume graphql over an authenticated websocket with subprotocol graphql-transport-ws is not working with the GraphQLTransportWSSubprotocolHandler as it lacks the means of payload in the connection init message:

the connection message cannot have a payload GraphQLTransportWSSubprotocolHandler.java#L78

   this.connectionInitMessage = Json.createObjectBuilder().add("type", "connection_init").build();

while in the protocol it states the message is

interface ConnectionInitMessage {
  type: 'connection_init';
  payload?: Record<string, unknown>;
}

typically used for auth-tokens etc.

edit: Better defining the problem

[phillip-kruger]

Hi @gabrielsson . Are you keen to do a PR to add this ? I assume you are looking for a way to add the payload to the init message ?

[gabrielsson]

@phillip-kruger Yes, I will take a look during this week!

[jmartisk]

The payload field is optional, hence the question mark behind it in the protocol specification. Therefore saying that "graphql-transport-ws is not working" isn't correct - we only have a limitation in that we don't offer an API for applications to specify that they want to pass some payload to clients this way. Is this what you need? It could be achievable, we just didn't yet see any compelling use case for supporting it.

[jmartisk]

Do you have any particular idea what the API should look like? How will the application define the payload items?

[gabrielsson]

@jmartisk I would say that in the best of worlds it should be possible alongside where we set headers on the connection

CLIENT_NAME/mp-graphql/header/KEY

something like

CLIENT_NAME/mp-graphql/initpayload/KEY

But that might be a stretch goal. As I am using the DynamicGraphQLClientBuilder.java I would start there.

[jmartisk]

It might need a way to specify the values dynamically because they might change over time, in which case a simple configuration property wouldn't work, but rather an SPI that the application will implement

[gabrielsson]

I would look at the payload as something which is negotiating the connection. I agree that it might be useful to have a dynamical approach to set the initial payload, but as only one connection_init message can be sent during a connection, I believe it is a good idea to start treating the init payload as we treat the header property.

[jmartisk]

~~There's one connection_init per connection, but over the runtime of a server, there will be tons of connections :)~~ Sorry yeah I somehow thought this was a server-side thing, disregard

But yeah, I'm not really sure how much dynamic it needs to be. It's not easy for me to imagine real-world use cases for this. Keeping it configuration-based will be much simpler to implement, and perhaps it will be enough, at least for start.

Also, how should we propagate this data to the server application? The server side library might want an API to be able to read this.

[jmartisk]

fixed via https://github.com/smallrye/smallrye-graphql/pull/1590