Returning subscription data

7. Returning subscription data

Overview

We're missing the important message data our subscription is listening for. In this lesson, we will:

Update our mutation resolver to pass along the payload data
See our subscription in action

Passing along the `Message`

Currently our mutation resolver is passing along an empty object ({}) as the payload of each "NEW_MESSAGE_SENT" event it publishes. Let's fix that.

Open up the resolvers/Mutation.ts file. Inside the sendMessage resolver, find the pubsub.publish function and make some space in that second argument: the empty object.

resolvers/Mutation.ts

await pubsub.publish("NEW_MESSAGE_SENT", {
  // TODO - pass along the actual submitted message!
});

To convey data directly to our subscription resolver, we'll first specify the name of that Subscription field: messageInConversation. This is an object which will take some additional properties.

await pubsub.publish("NEW_MESSAGE_SENT", {
  messageInConversation: {},
});

The properties inside this object will be exactly what our Subscription.messageInConversation resolver will return for each new event. This is where the return type we defined in our schema comes in: we need to make sure that we pass along an object that matches the shape of our schema's Message type.

Taking another look at the Message type, we'll see exactly the properties we need to include. (We're omitting the field descriptions here for easier readability.)

type Message {
  id: ID!
  text: String!
  sentFrom: User!
  sentTo: User!
  sentTime: String
}

Good news, we already have access to these properties in the sendMessage resolver! At the top of the function, we can see that these properties are available and have already been destructured from the dataSources.db.sendMessageToConversation call.

Let's pass them in now to our object.

await pubsub.publish("NEW_MESSAGE_SENT", {
  messageInConversation: {
    id,
    text: messageText,
    sentFrom,
    sentTo,
    sentTime,
  },
});

Note that we're renaming the messageText field to simply text, to match the field name in the schema.

Testing the subscription

It's time to put our subscription to the test! First, make sure that both subgraphs and the rover dev process are still running. Then jump over to http://localhost:4000.

If you saved your subscription operation at the start of the course, now's the time to access it in from your Operation Collection! Otherwise, copy and paste the operation below into the Explorer's Operation field.

subscription SubscribeToMessagesInConversation($messageInConversationId: ID!) {
  messageInConversation(id: $messageInConversationId) {
    text
    sentTime
  }
}

And in the Variables panel:

Variables

{
  "messageInConversationId": "wardy-eves-chat"
}

And in the Headers panel:

Headers

Authorization: Bearer eves

Submit the operation. At the bottom of the Response panel a new window labeled Subscriptions appears: we should see a green status indicator, along with a message that the router is listening for new events.

http://localhost:4000

A screenshot of Sandbox, showing a subscription running successfully

Next, let's open up a new operation tab. This time, we'll access our saved SendMessageToConversation operation.

mutation SendMessageToConversation($message: NewMessageInput!) {
  sendMessage(message: $message) {
    id
    text
    sentTo {
      id
      name
    }
  }
}

Add the following to the Variables panel:

Variables

{
  "message": {
    "conversationId": "wardy-eves-chat",
    "text": "I'm offering a discount of up to 60%!"
  }
}

Finally, make sure that you're still passing along the correct values for your Authorization header!

Headers

Authorization: Bearer eves

Submit the mutation and... data! We should see both the response from the mutation, as well as the new event in our Subscriptions panel! Our subscription is working!

http://localhost:4000

A screenshot of Sandbox, showing both mutation and subscription data in the Response panel

Practice

Subscribing to data

Whenever our sendMessage mutation is called, we use the server's PubSub instance to call the

method. This method accepts two arguments: the

and the

. Inside our subscribe function, we use the server's PubSub instance to call the

method. This method accepts an

of event names whose payload should be iterated over and returned.

Drag items from this box to the blanks above

asyncIterator
trigger
payload
event name
subscribe
destination
object
array
metadata
publish

Refer to the following schema to complete the code challenge below.

type Subscription {
  "Subscribe to changes in a mission status"
  newMissionStatus(id: ID!): Mission
}

type Mutation {
  "Update the status for a particular mission"
  changeMissionStatus(missionId: ID!, status: String!): Mission
}

Code Challenge!

Update the resolver for Mutation.changeMissionStatus to publish an event called STATUS_UPDATE. Include the entire mission object.

Key takeaways

We can use the PubSub method publish to pass along the data that should arrive in subscribe functions listening for the same event. This data should match the return type we specified for our subscription field in the schema.

Up next

Our subscription is working! But we have some opportunities for optimization. Let's dive into those in the next lesson.

Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.