Subscription lifecycle in GraphQL - Step-by-Step Execution

Concept Flow - Subscription lifecycle

Client subscribes

↓

Server registers subscription

↓

Server listens for events

↓

Event occurs

↓

Server sends data update

↓

Client receives update

↓

Client may unsubscribe

↓

Server cleans up subscription

This flow shows how a client starts a subscription, the server listens and sends updates, and how the subscription ends.

Execution Sample

GraphQL

subscription {
  newMessage {
    id
    content
  }
}

This subscription listens for new messages and receives their id and content when they arrive.

Execution Table

Step	Action	Server State	Client State	Data Sent	Notes
1	Client sends subscription request	Registers subscription for newMessage	Waiting for data	None	Subscription starts
2	Server listens for newMessage events	Listening active	Waiting for data	None	Ready to send updates
3	New message event occurs	Event detected	Waiting for data	None	Event triggers data send
4	Server sends newMessage data	Sends {id:1, content:'Hi'}	Receives data	{id:1, content:'Hi'}	Client gets update
5	Client processes data	Listening active	Data received	{id:1, content:'Hi'}	Client updates UI
6	Client unsubscribes	Removes subscription	Subscription ended	None	Subscription ends
7	Server cleans up resources	No active subscription	Subscription ended	None	Cleanup done

💡 Subscription ends when client unsubscribes and server cleans up

Variable Tracker

Variable	Start	After Step 1	After Step 4	After Step 6	Final
subscriptionActive	false	true	true	false	false
dataReceived	none	none	{id:1, content:'Hi'}	{id:1, content:'Hi'}	{id:1, content:'Hi'}

Key Moments - 3 Insights

Why does the server keep the subscription active after sending data?

Because subscriptions stay open to send future updates until the client unsubscribes, as shown in steps 4 and 5.

What happens if the client never unsubscribes?

The server keeps the subscription active and continues sending updates when events occur, as seen in steps 2 to 5.

When does the server clean up the subscription?

Only after the client unsubscribes, as shown in steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the client first receive data?

A Step 5

B Step 2

C Step 4

D Step 6

💡 Hint

Check the 'Data Sent' column in the execution table rows

According to the variable tracker, when does 'subscriptionActive' become false?

A After Step 1

B After Step 6

C After Step 4

D At Start

💡 Hint

Look at the 'subscriptionActive' row values in variable_tracker

If the client never unsubscribes, what would happen to the server state?

A Server keeps listening and sending updates

B Server removes subscription immediately

C Server sends data once then stops

D Server crashes

💡 Hint

Refer to key_moments about subscription lifecycle and server behavior

Concept Snapshot

GraphQL Subscription Lifecycle:
- Client sends subscription request
- Server registers and listens for events
- Server sends data updates on events
- Client receives and processes updates
- Subscription stays open until client unsubscribes
- Server cleans up after unsubscribe

Full Transcript

This visual execution shows the lifecycle of a GraphQL subscription. First, the client sends a subscription request. The server registers this subscription and listens for relevant events. When an event occurs, the server sends data to the client. The client receives and processes this data. The subscription remains active, allowing multiple updates. When the client decides to unsubscribe, the server removes the subscription and cleans up resources. Variables like subscriptionActive track whether the subscription is open. This lifecycle ensures real-time data flow until the client ends it.

Practice

1. What is the main purpose of a subscription in GraphQL?

easy

A. To fetch data only once from the server

B. To update data on the server

C. To delete data from the database

D. To receive real-time updates when data changes

Solution

1. Step 1: Understand the role of subscriptions

   Subscriptions are designed to keep the client updated automatically when data changes on the server.

2. Step 2: Compare with other GraphQL operations

   Queries fetch data once, mutations change data, but subscriptions push live updates.

3. Final Answer:

   To receive real-time updates when data changes -> Option D

4. Quick Check:

   Subscriptions = real-time updates [OK]

Hint: Subscriptions push live data updates automatically [OK]

Common Mistakes:

• Confusing subscriptions with queries
• Thinking subscriptions modify data
• Believing subscriptions fetch data only once

2. Which of the following is the correct syntax to start a GraphQL subscription named newMessage that listens for content and sender fields?

easy

A. subscription { newMessage { content sender } }

B. query { newMessage { content sender } }

C. mutation { newMessage { content sender } }

D. subscribe { newMessage { content sender } }

Solution

1. Step 1: Identify the correct keyword for subscriptions

   The keyword to start a subscription is subscription, not query, mutation, or subscribe.

2. Step 2: Check the structure of the subscription

   The subscription should specify the event name and requested fields inside curly braces.

3. Final Answer:

   subscription { newMessage { content sender } } -> Option A

4. Quick Check:

   Subscription syntax = subscription keyword + event + fields [OK]

Hint: Use 'subscription' keyword, not 'query' or 'mutation' [OK]

Common Mistakes:

• Using 'query' or 'mutation' instead of 'subscription'
• Using 'subscribe' keyword which is invalid
• Missing curly braces around fields

3. Given this subscription:

subscription { newNotification { id message } }

What will the client receive when a new notification with id: 5 and message: "Hello" is sent?

medium

A. { "data": { "newNotification": { "id": 5, "message": "Hello" } } }

B. { "data": { "newNotification": { "id": "5", "message": "Hello" } } }

C. { "error": "Subscription not found" }

D. { "data": { "newNotification": { "message": "Hello" } } }

Solution

1. Step 1: Understand subscription response format

   Subscriptions return data wrapped in a data object with the event name as key and requested fields as nested data.

2. Step 2: Match the expected data types and fields

   The id is a number 5, and message is "Hello". Both fields are included as requested.

3. Final Answer:

   { "data": { "newNotification": { "id": 5, "message": "Hello" } } } -> Option A

4. Quick Check:

   Subscription data = event with requested fields [OK]

Hint: Subscription returns data object with event and fields [OK]

Common Mistakes:

• Returning id as string instead of number
• Missing fields in response
• Expecting error when subscription is valid

4. You wrote this subscription:

subscription { newMessage { content sender } }

But your client never receives updates. Which is the most likely cause?

medium

A. The client is using a query instead of a subscription

B. The subscription syntax is invalid

C. The server does not publish events for newMessage

D. The fields content and sender do not exist

Solution

1. Step 1: Check subscription syntax

   The syntax is correct, so syntax errors are unlikely.

2. Step 2: Consider server event publishing

   If the server never sends events for newMessage, the client won't get updates.

3. Step 3: Verify client usage

   The client uses subscription syntax, so it's not using a query.

4. Step 4: Confirm fields existence

   Assuming fields exist, the main issue is missing server events.

5. Final Answer:

   The server does not publish events for newMessage -> Option C

6. Quick Check:

   No server events = no subscription updates [OK]

Hint: Check if server sends events for the subscription [OK]

Common Mistakes:

• Assuming syntax error without checking server
• Confusing query with subscription on client
• Ignoring server-side event publishing

5. You want to create a subscription that only sends updates when a new chat message is sent by user "Alice". Which subscription definition correctly filters messages by sender?

hard

A. subscription { newMessage { content sender } where sender = "Alice" }

B. subscription { newMessage(sender: "Alice") { content sender } }

C. subscription { newMessage { content sender } filter: sender == "Alice" }

D. subscription { newMessage { content sender } if sender = "Alice" }

Solution

1. Step 1: Understand argument usage in subscriptions

   GraphQL subscriptions accept arguments like queries to filter events, e.g., newMessage(sender: "Alice").

2. Step 2: Identify invalid syntax options

   Options B, C, and D use invalid keywords or syntax (where, filter, if) which are not part of GraphQL subscription syntax.

3. Final Answer:

   subscription { newMessage(sender: "Alice") { content sender } } -> Option B

4. Quick Check:

   Use arguments in subscription for filtering [OK]

Hint: Filter subscriptions using arguments inside parentheses [OK]

Common Mistakes:

• Using SQL-like WHERE or IF clauses in subscription
• Trying to filter inside selection set
• Not passing filter as argument