5 exercises on GraphQL subscriptions — WebSocket transport, pub/sub patterns, and connection lifecycle.
0 / 5 completed
1 / 5
What is a GraphQL subscription used for?
Subscription: unlike queries (request/response), subscriptions set up a persistent connection. When the server-side event fires (e.g. a new message), the server pushes data to all subscribing clients. The GraphQL spec leaves the transport unspecified, but WebSocket (graphql-ws protocol) is standard.
2 / 5
Why do GraphQL subscriptions typically use WebSocket rather than HTTP?
WebSocket for subscriptions: HTTP/1.1 requires the client to initiate every exchange. WebSocket upgrades to a bidirectional connection, allowing the server to push subscription payloads at any time — essential for truly real-time behaviour.
3 / 5
What is the role of pub/sub in a distributed GraphQL subscription setup?
Pub/sub for subscriptions: in a multi-instance deployment, a mutation on server A must reach clients connected to server B. A pub/sub broker (Redis Pub/Sub, Kafka) lets server A publish the event and server B, subscribed to that channel, delivers it to its connected clients.
4 / 5
What happens during the connection lifecycle of a GraphQL subscription over WebSocket?
graphql-ws protocol lifecycle: the client sends connection_init, receives connection_ack, then sends subscribe with the query. The server emits next messages for each event and complete when done. Either side can send complete to end a subscription.
5 / 5
What is a subscription resolver and what must it return?
Subscription resolver: the subscribe function returns an async iterator — commonly from a pub/sub library's asyncIterator() method. The optional resolve function transforms each event payload before it is sent to the client.