Subscription lifecycle in GraphQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start a subscription for a user.

GraphQL

mutation StartSubscription { startSubscription(userId: [1]) { id status } }

Drag options to blanks, or click blank then click option'

AuserId

B12345

C"12345"

DsubscriptionId

Attempts:

3 left

💡 Hint

Common Mistakes

Using an unquoted number for userId causes syntax errors.

Using variable names instead of actual values.

The userId must be a string in quotes in GraphQL mutations.

2fill in blank

medium

Complete the code to query the subscription status.

GraphQL

query GetSubscriptionStatus { subscription(id: [1]) { status } }

Drag options to blanks, or click blank then click option'

A"sub_001"

B123

Cstatus

DuserId

Attempts:

3 left

💡 Hint

Common Mistakes

Using unquoted IDs causes errors.

Confusing field names with ID values.

Subscription IDs are strings and must be quoted in GraphQL queries.

3fill in blank

hard

Fix the error in the mutation to cancel a subscription.

GraphQL

mutation CancelSubscription { cancelSubscription(id: [1]) { id status } }

Drag options to blanks, or click blank then click option'

A"sub_123"

Bid

CsubscriptionId

Dsub_123

Attempts:

3 left

💡 Hint

Common Mistakes

Omitting quotes around string IDs.

Using variable names instead of actual values.

The subscription ID must be a string in quotes for the mutation to work.

4fill in blank

hard

Fill both blanks to query active subscriptions for a user.

GraphQL

query ActiveSubscriptions { user(id: [1]) { subscriptions(status: [2]) { id } } }

Drag options to blanks, or click blank then click option'

A"user_789"

B"active"

C"inactive"

DuserId

Attempts:

3 left

💡 Hint

Common Mistakes

Using unquoted strings for IDs or status.

Using wrong status values.

User ID and status must be strings in quotes in GraphQL queries.

5fill in blank

hard

Fill all three blanks to update subscription status with a mutation.

GraphQL

mutation UpdateSubscription { updateSubscription(id: [1], status: [2]) { id [3] } }

Drag options to blanks, or click blank then click option'

A"sub_456"

B"paused"

Cstatus

DuserId

Attempts:

3 left

💡 Hint

Common Mistakes

Not quoting string arguments.

Returning wrong fields in the response.

The subscription ID and status must be strings, and the field to return is 'status'.

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