Subscription lifecycle in GraphQL

Introduction

Subscriptions let you get live updates from the database. They keep you informed when data changes without asking again and again.

You want to see new messages in a chat app as soon as they arrive.

You need to update a dashboard when sales numbers change.

You want to show live scores in a sports app.

You want to track real-time location updates on a map.

You want to notify users instantly when their order status changes.

Syntax

GraphQL

subscription SubscriptionName {
  eventName {
    field1
    field2
  }
}

Use the keyword subscription instead of query to start a subscription.

Inside the subscription, specify the event or data you want to listen to and the fields you want to receive.

Examples

This subscription listens for new messages and returns their id, content, and sender.

GraphQL

subscription OnNewMessage {
  newMessage {
    id
    content
    sender
  }
}

This subscription listens for updates to orders and returns the order ID and new status.

GraphQL

subscription OnOrderUpdate {
  orderUpdated {
    orderId
    status
  }
}

Sample Program

This subscription listens for new users added to the database and returns their id, name, and email.

GraphQL

subscription OnNewUser {
  userAdded {
    id
    name
    email
  }
}

Important Notes

Subscriptions keep the connection open to send updates as they happen.

They are great for real-time apps but can use more resources than simple queries.

Make sure your server supports subscriptions and you handle connection errors gracefully.

Summary

Subscriptions let you get live updates automatically.

Use the subscription keyword and specify the event and fields.

They are perfect for chat apps, live dashboards, and notifications.

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