7. Returning subscription data
10m

Overview

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

  • Update our to pass along the payload data
  • See our in action

Passing along the Message

Currently our 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 , find the pubsub.publish function and make some space in that second : 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 , we'll first specify the name of that Subscription : listenForMessageInConversation. This is an object which will take some additional properties.

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

The properties inside this object will be exactly what our Subscription.listenForMessageInConversation 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 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 ! 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", {
listenForMessageInConversation: {
id,
text: messageText,
sentFrom,
sentTo,
sentTime,
},
});

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

Testing the subscription

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

If you saved your 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 .

subscription SubscribeToMessagesInConversation(
$listenForMessageInConversationId: ID!
) {
listenForMessageInConversation(id: $listenForMessageInConversationId) {
text
sentTime
}
}

And in the Variables panel:

Variables
{
"listenForMessageInConversationId": "wardy-eves-chat"
}

And in the Headers panel:

Headers
Authorization: Bearer eves

Submit the . 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 is listening for new events.

http://localhost:4000

A screenshot of Sandbox, showing a subscription running successfully

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

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 and... data! We should see both the response from the mutation, as well as the new event in our Subscriptions panel! Our 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

  • trigger

  • subscribe

  • publish

  • asyncIterator

  • metadata

  • payload

  • object

  • event name

  • destination

  • array

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 in the schema.

Up next

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

Previous

Share your questions and comments about this lesson

This course is currently in

beta
. 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.