Subscription resolvers in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this subscription resolver?

Consider this GraphQL subscription resolver snippet:

subscription {
  messageAdded(roomId: "123") {
    id
    content
  }
}

Assuming a new message with id: "m1" and content: "Hello" is added to room 123, what will the subscription deliver?

GraphQL

subscription {
  messageAdded(roomId: "123") {
    id
    content
  }
}

A {"data": {"messageAdded": {"content": "Hello"}}}

B {"data": {"messageAdded": {"id": "m1"}}}

C {"data": {"messageAdded": {"id": "m1", "content": "Hello"}}}

D {"errors": [{"message": "Room not found"}]}

💡 Hint

Subscriptions send the full data requested when the event occurs.

The subscription resolver sends the full id and content fields of the new message added to the specified room.

🧠 Conceptual

intermediate

Which statement best describes a subscription resolver?

Choose the correct description of a GraphQL subscription resolver.

A It handles real-time data by pushing updates to clients when events occur.

B It fetches data only once when a query is executed.

C It modifies data in the database when a mutation is called.

D It caches query results to improve performance.

💡 Hint

Think about what makes subscriptions different from queries and mutations.

Subscription resolvers enable real-time updates by pushing data to clients when specific events happen.

📝 Syntax

advanced

Identify the syntax error in this subscription resolver code

Which option contains the correct syntax for a subscription resolver in GraphQL?

const resolvers = {
  Subscription: {
    messageAdded: {
      subscribe: (parent, args, context, info) => {
        return pubsub.asyncIterator('MESSAGE_ADDED')
      }
    }
  }
}

A subscribe should be a function returning a Promise, not an asyncIterator.

B Correct as is, no syntax errors.

C Missing parentheses after asyncIterator: pubsub.asyncIterator 'MESSAGE_ADDED'

D Subscription should be lowercase: subscription.

💡 Hint

Check the use of asyncIterator and function syntax.

The code correctly defines a subscription resolver using asyncIterator to listen for events.

🔧 Debug

advanced

Why does this subscription resolver not send updates?

Given this subscription resolver:

Subscription: {
  messageAdded: {
    subscribe: (parent, args, context) => {
      if (!args.roomId) {
        throw new Error('roomId is required')
      }
      return pubsub.asyncIterator('MESSAGE_ADDED')
    }
  }
}

Clients subscribe with messageAdded(roomId: "123") but receive no updates when messages are added. What is the likely cause?

A The asyncIterator listens to 'MESSAGE_ADDED' without filtering by roomId, so no matching events are sent.

B The subscription resolver throws an error because roomId is missing.

C The pubsub.asyncIterator method is deprecated and does not work.

D The subscribe function must be async to work properly.

💡 Hint

Think about how events are filtered for specific rooms.

The asyncIterator listens to all 'MESSAGE_ADDED' events but does not filter by roomId, so clients subscribed to a specific room get no matching events.

❓ optimization

expert

How to optimize subscription resolver for multiple rooms efficiently?

You want to support subscriptions for messages added to multiple rooms. Which approach optimizes resource use and avoids unnecessary event delivery?

A Use a single asyncIterator for all 'MESSAGE_ADDED' events and filter messages by roomId inside the resolver before sending.

B Use polling queries instead of subscriptions to reduce server load.

C Send all 'MESSAGE_ADDED' events to all clients and let clients filter messages on their side.

D Create a separate asyncIterator for each roomId and subscribe clients only to their room's iterator.

💡 Hint

Consider how to minimize unnecessary data sent to clients.

Creating separate asyncIterators per room allows sending only relevant events to subscribed clients, reducing overhead and improving efficiency.