Subscription resolvers in GraphQL - Step-by-Step Execution

Concept Flow - Subscription resolvers

Client subscribes to event

↓

Server receives subscription request

↓

Subscription resolver sets up event listener

↓

Event occurs on server

↓

Resolver pushes updated data to client

↓

Client receives real-time update

↓

Subscription stays open until client disconnects

The flow shows how a client subscribes to real-time events, the server listens and sends updates as events happen.

Execution Sample

GraphQL

subscription {
  messageAdded {
    id
    content
    author
  }
}

Client subscribes to new messages; server sends each new message as it arrives.

Execution Table

Step	Action	Resolver State	Event Occurred?	Data Sent to Client
1	Client sends subscription request	Waiting for events	No	No data
2	Server sets up subscription resolver	Listening for messageAdded events	No	No data
3	New messageAdded event occurs	Listening	Yes	New message data sent
4	Client receives new message	Listening	No	Data received
5	Another messageAdded event occurs	Listening	Yes	New message data sent
6	Client disconnects	Subscription closed	No	No data

💡 Client disconnects, subscription resolver stops sending data

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
subscriptionState	None	Listening	Listening	Listening	Closed
eventData	None	None	Message 1	Message 2	None
clientConnection	Disconnected	Connected	Connected	Connected	Disconnected

Key Moments - 3 Insights

Why does the subscription resolver keep running after sending data once?

Because subscriptions are designed to keep the connection open and send data every time the event occurs, as shown in steps 3 and 5 in the execution_table.

What happens if the client disconnects?

The subscription resolver stops sending data and closes the connection, as shown in step 6 in the execution_table.

Does the server send data before any event occurs?

No, the server only sends data when the subscribed event happens, shown by 'No data' in steps 1 and 2.

Visual Quiz - 3 Questions

Look at the execution_table, what is the resolver state after the client sends the subscription request?

A Listening for messageAdded events

B Waiting for events

C Subscription closed

D Disconnected

💡 Hint

Check Step 1 and Step 2 in the execution_table under Resolver State

At which step does the client receive the first real-time update?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for 'Client receives new message' in the execution_table

If the client disconnects earlier, how does the subscriptionState variable change in variable_tracker?

A It changes to 'Closed'

B It becomes 'None'

C It stays 'Listening'

D It becomes 'Disconnected'

💡 Hint

See the 'subscriptionState' row in variable_tracker at the Final column

Concept Snapshot

Subscription resolvers handle real-time data by keeping a connection open.
Client subscribes to an event.
Server listens and sends data when events occur.
Connection stays open until client disconnects.
Used for live updates like chat messages or notifications.

Full Transcript

Subscription resolvers in GraphQL allow clients to receive real-time updates. The client sends a subscription request, and the server sets up a resolver that listens for specific events. When an event occurs, the server pushes updated data to the client. This connection remains open, sending data whenever new events happen, until the client disconnects. This flow enables live data features such as chat messages or notifications.