Subscription lifecycle in GraphQL - Mini Project: Build & Apply

Subscription Lifecycle Management with GraphQL

📖 Scenario: You are building a simple subscription management system for a magazine service. Customers can subscribe to different magazines, and you want to track their subscription status and details using GraphQL.

🎯 Goal: Create a GraphQL schema and queries to manage and retrieve subscription lifecycle data, including subscriber information, subscription plans, and status.

📋 What You'll Learn

Define a GraphQL type Subscriber with fields id, name, and email.

Define a GraphQL type Subscription with fields id, subscriberId, plan, and status.

Create a query subscriptions to retrieve all subscriptions.

Create a query activeSubscriptions to retrieve subscriptions with status ACTIVE.

💡 Why This Matters

🌍 Real World

Subscription lifecycle management is common in services like magazines, streaming platforms, and SaaS products to track user subscriptions and their status.

💼 Career

Understanding GraphQL schema design and queries is essential for backend developers working with modern APIs and subscription-based services.

1

Define Subscriber and Subscription Types

Define a GraphQL type called Subscriber with fields id of type ID!, name of type String!, and email of type String!. Also define a GraphQL type called Subscription with fields id of type ID!, subscriberId of type ID!, plan of type String!, and status of type String!.

GraphQL

# Define Subscriber and Subscription types
# Your code here

Hint

Use type keyword to define GraphQL types. Use ! to mark fields as required.

2

Add Query Type with subscriptions Field

Add a GraphQL Query type with a field called subscriptions that returns a list of Subscription objects. Use [Subscription!]! as the return type to indicate a non-null list of non-null subscriptions.

GraphQL

type Subscriber {
  id: ID!
  name: String!
  email: String!
}

type Subscription {
  id: ID!
  subscriberId: ID!
  plan: String!
  status: String!
}

# Add Query type with subscriptions field
# Your code here

Hint

Define a Query type with a field returning a list of subscriptions.

3

Add activeSubscriptions Query with Status Filter

Add a field called activeSubscriptions to the Query type that returns a list of Subscription objects with status ACTIVE. Use the same return type [Subscription!]!.

GraphQL

type Subscriber {
  id: ID!
  name: String!
  email: String!
}

type Subscription {
  id: ID!
  subscriberId: ID!
  plan: String!
  status: String!
}

type Query {
  subscriptions: [Subscription!]!
  # Add activeSubscriptions field
  # Your code here
}

Hint

Add the activeSubscriptions field to the Query type with the correct return type.

4

Complete Schema with Subscription Status Enum

Add an enum type called SubscriptionStatus with values ACTIVE, CANCELLED, and PAUSED. Update the status field in Subscription type to use SubscriptionStatus! instead of String!.

GraphQL

type Subscriber {
  id: ID!
  name: String!
  email: String!
}

type Subscription {
  id: ID!
  subscriberId: ID!
  plan: String!
  status: String!
}

type Query {
  subscriptions: [Subscription!]!
  activeSubscriptions: [Subscription!]!
}

# Add SubscriptionStatus enum and update status field
# Your code here

Hint

Use enum to define fixed status values and update the status field type accordingly.

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