Subscription resolvers in GraphQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a subscription resolver that listens for new messages.

GraphQL

const resolvers = {
  Subscription: {
    newMessage: {
      subscribe: [1]
    }
  }
};

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

Apubsub.listen('NEW_MESSAGE')

Bpubsub.publish('NEW_MESSAGE')

Cpubsub.subscribe('NEW_MESSAGE')

Dpubsub.asyncIterator('NEW_MESSAGE')

Attempts:

3 left

💡 Hint

Common Mistakes

Using pubsub.publish instead of asyncIterator

Calling a non-existent pubsub.listen method

The subscribe function must return an async iterator from pubsub.asyncIterator to listen for events.

2fill in blank

medium

Complete the code to publish a new message event after saving the message.

GraphQL

async function sendMessage(message) {
  await saveMessageToDB(message);
  pubsub.[1]('NEW_MESSAGE', { newMessage: message });
}

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

Asubscribe

BasyncIterator

Cpublish

Dlisten

Attempts:

3 left

💡 Hint

Common Mistakes

Using subscribe instead of publish

Trying to call asyncIterator to send events

To notify subscribers, use pubsub.publish with the event name and payload.

3fill in blank

hard

Fix the error in the subscription resolver to correctly return the async iterator.

GraphQL

Subscription: {
  messageAdded: {
    subscribe() {
      return pubsub.[1]('MESSAGE_ADDED');
    }
  }
}

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

AasyncIterator

Bpublish

Csubscribe

Dlisten

Attempts:

3 left

💡 Hint

Common Mistakes

Returning pubsub.publish instead of asyncIterator

Using a non-existent listen method

The resolver must return pubsub.asyncIterator to create an async iterator for the subscription.

4fill in blank

hard

Fill both blanks to create a subscription resolver that filters messages by channel.

GraphQL

Subscription: {
  messageByChannel: {
    subscribe: withFilter(
      () => pubsub.[1]('MESSAGE_SENT'),
      (payload, variables) => payload.channelId [2] variables.channelId
    )
  }
}

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

AasyncIterator

B===

C!==

Dpublish

Attempts:

3 left

💡 Hint

Common Mistakes

Using publish instead of asyncIterator

Using !== instead of === in the filter

Use pubsub.asyncIterator to listen for events and === to filter messages matching the channel ID.

5fill in blank

hard

Fill all three blanks to define a subscription resolver with a filter and a custom resolve function.

GraphQL

Subscription: {
  commentAdded: {
    subscribe: withFilter(
      () => pubsub.[1]('COMMENT_ADDED'),
      (payload, variables) => payload.postId [2] variables.postId
    ),
    resolve: (payload) => payload.[3]
  }
}

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

AasyncIterator

B===

Ccomment

Dpublish

Attempts:

3 left

💡 Hint

Common Mistakes

Using publish instead of asyncIterator

Using !== instead of === in filter

Returning wrong property in resolve

The subscription uses asyncIterator to listen, === to filter by postId, and the resolve function returns the comment from the payload.

Practice

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

easy

A. To modify data on the server

B. To fetch data only once when a query is made

C. To provide real-time updates to clients when data changes

D. To define the schema types

Solution

1. Step 1: Understand the role of subscription resolvers

   Subscription resolvers are designed to send data updates automatically as events happen, unlike queries which fetch data once.

2. Step 2: Compare with other resolver types

   Queries fetch data once, mutations modify data, and schema defines types. Only subscriptions provide live updates.

3. Final Answer:

   To provide real-time updates to clients when data changes -> Option C

4. Quick Check:

   Subscription = real-time updates [OK]

Hint: Subscriptions push live data updates automatically [OK]

Common Mistakes:

• Confusing subscriptions with queries
• Thinking subscriptions modify data
• Mixing schema definition with resolver purpose

2. Which of the following is the correct way to declare a subscription resolver in GraphQL SDL?

easy

A. type Subscription { newMessage: Message }

B. type Query { newMessage: Message }

C. type Mutation { newMessage: Message }

D. type Resolver { newMessage: Message }

Solution

1. Step 1: Identify the correct GraphQL operation keyword

   Subscriptions use the type Subscription keyword to declare real-time data streams in the schema.

2. Step 2: Check other operation keywords

   Queries use type Query, mutations use type Mutation, and type Resolver is not a valid keyword.

3. Final Answer:

   type Subscription { newMessage: Message } -> Option A

4. Quick Check:

   Subscription keyword = subscription declaration [OK]

Hint: Use 'type Subscription' keyword to declare live data streams [OK]

Common Mistakes:

• Using 'type Query' or 'type Mutation' instead of 'type Subscription'
• Trying to use 'type Resolver' keyword
• Misplacing subscription declaration outside schema

3. Given this subscription resolver code snippet, what will be the output when a new message is published?

const resolvers = {
  Subscription: {
    newMessage: {
      subscribe: () => pubsub.asyncIterator(['MESSAGE_ADDED'])
    }
  }
};

medium

A. The client receives updates only when a message is added

B. The client receives all past messages immediately

C. The client receives no updates until a query is made

D. The client receives an error because subscribe is missing

Solution

1. Step 1: Understand the subscribe function

   The subscribe function returns an async iterator for the event 'MESSAGE_ADDED', so it listens for new messages.

2. Step 2: Determine what triggers updates

   Updates are sent only when the 'MESSAGE_ADDED' event occurs, so clients get notified only on new messages.

3. Final Answer:

   The client receives updates only when a message is added -> Option A

4. Quick Check:

   Subscription triggers on event = client updates [OK]

Hint: Subscribe returns async iterator for live event updates [OK]

Common Mistakes:

• Assuming all past data is sent immediately
• Thinking updates require queries first
• Missing that subscribe returns async iterator

4. Identify the error in this subscription resolver code:

const resolvers = {
  Subscription: {
    newNotification: {
      subscribe: pubsub.asyncIterator('NOTIFICATION_ADDED')
    }
  }
};

medium

A. The resolver key should be 'Query' instead of 'Subscription'

B. The event name should be an array, not a string

C. Subscription resolvers cannot use pubsub

D. The subscribe function should be a function returning asyncIterator, not the asyncIterator itself

Solution

1. Step 1: Check the subscribe property type

   The subscribe property must be a function that returns the async iterator, not the async iterator itself.

2. Step 2: Verify correct usage of asyncIterator

   It should be subscribe: () => pubsub.asyncIterator('NOTIFICATION_ADDED') to work properly.

3. Final Answer:

   The subscribe function should be a function returning asyncIterator, not the asyncIterator itself -> Option D

4. Quick Check:

   Subscribe must be a function returning asyncIterator [OK]

Hint: Subscribe must be a function returning asyncIterator [OK]

Common Mistakes:

• Assigning asyncIterator directly instead of a function
• Using string instead of array for event names (optional)
• Confusing subscription with query resolvers

5. You want to create a subscription that only sends updates to clients when a new comment is added to a specific post ID. Which resolver implementation correctly filters events by post ID?

const resolvers = {
  Subscription: {
    commentAdded: {
      subscribe: (parent, args, { pubsub }) => {
        return pubsub.asyncIterator('COMMENT_ADDED');
      },
      resolve: (payload, args) => {
        if (payload.postId === args.postId) {
          return payload;
        }
        return null;
      }
    }
  }
};

hard

A. The filtering should be done inside the subscribe function, not resolve

B. This implementation correctly filters comments by postId in the resolve function

C. The asyncIterator should listen to an array of post IDs, not a single event

D. Subscriptions cannot filter events by arguments

Solution

1. Step 1: Understand event filtering in subscriptions

   The resolve function can filter events by checking if the payload matches the subscription arguments.

2. Step 2: Check the given code logic

   The code returns the payload only if payload.postId === args.postId, otherwise returns null to skip irrelevant events.

3. Final Answer:

   This implementation correctly filters comments by postId in the resolve function -> Option B

4. Quick Check:

   Filtering in resolve function = correct approach [OK]

Hint: Filter events in resolve by comparing payload and args [OK]

Common Mistakes:

• Trying to filter inside subscribe instead of resolve
• Expecting asyncIterator to filter by arguments automatically
• Believing subscriptions cannot filter events