SubscribePayload support for query/id

[artola]

Source code

graphql-ws/src/common.ts

Line 93 in e3b81fa

export interface SubscribePayload {

Expected Behaviour
SubscribePayload should support query (text) or id (hashed query) for persisted queries (might be an union type).

Actual Behaviour
Only query is allowed and it is required.

[enisdenjo]

Hey there! Simply use the query field to transmit the hash ID. Please check the "ws server and client usage with persisted queries" recipe.

[artola]

@enisdenjo Thanks and sorry, I did not see the recipe.

[enisdenjo]

Hey @artola, quick heads up: [email protected] just landed, adding the extensions field in the subscribe message payload.

This means that you now can pass along the persistedQuery through that field on each subscribe as various other libraries/frameworks suggest.

[artola]

@enisdenjo Thanks for the info. But still I have my doubts about the query property as you know still it is required.

graphql-ws/src/common.ts

Line 95 in 2933997

readonly query: string;

At least should be optional or null if it is not intended to be used.

FYI @michaelstaib

[michaelstaib]

@enisdenjo @artola lets do a PR to the actual HTTP spec to first get this change into the HTTP spec. I spoke to @IvanGoncharov about persisted queries a while ago and the general idea was to move the top-level id into extensions. But we never actually discussed that query can become optional in the you pass along id. In general that would mean query can be null when extension is set. The validation is then up to the server.

This for instance this how an apollo persisted query request looks like.

{
  "extensions": {
    "persistedQuery": {
      "version": 1,
      "sha256Hash": "ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"
    }
  }
}

So let me do a PR to the HTTP spec and then discuss things on that repo.

[michaelstaib]

I will write something to the following issue:
graphql/graphql-over-http#38

[enisdenjo]

I try mirroring the HTTP spec as much as possible.

Having said that, if we make the query field optional there, no reason to keep it required in the WS spec.