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.
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: 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
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", {listenForMessageInConversation: {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($listenForMessageInConversationId: ID!) {listenForMessageInConversation(id: $listenForMessageInConversationId) {textsentTime}}
And in the Variables panel:
{"listenForMessageInConversationId": "wardy-eves-chat"}
And in the Headers panel:
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.
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) {idtextsentTo {idname}}}
Add the following to the Variables panel:
{"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!
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!
Practice
sendMessage
mutation is called, we use the server's PubSub
instance to call the subscribe
function, we use the server's PubSub
instance to call the 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
methodpublish
to pass along the data that should arrive insubscribe
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
This course is currently in
You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.