Codealong - Add Subscription and Mutation types

3. Codealong - Add Subscription and Mutation types

10m

Overview

In this codealong, we'll add the Subscription and Mutation types to our schema.

Our Subscription field will subscribe us to new messages in a given conversation, while the Mutation field we add will send new messages to a given conversation.

In the messages directory, let's jump into src/schema.graphql.

The `Subscription` type

Let's start with the Subscription type. We'll add the new type our schema, along with its field: listenForMessageInConversation. This field should accept an argument, id, for the conversation it listens to, and it should return a Message type.

messages/src/schema.graphql

type Subscription {
  # Start a new subscription for messages in a particular conversation, with an optional timestamp cursor to replay from
  listenForMessageInConversation(id: ID!): Message
}

The new `Mutation` field

Our schema already has a Mutation type with one field: but we need to take care of adding the field that allows us to send a new message to a conversation.

We'll add to our existing Mutation type a field called sendMessage. This field should accept an argument called message, which is a non-nullable NewMessageInput type. This field will simply return the Message (nullable, because it could fail).

type Mutation {
  # Initiate a new conversation with a particular user
  createConversation(recipientId: ID!): Conversation
  # Submit a new message to a specified conversation
  sendMessage(message: NewMessageInput!): Message
}

Publishing our changes

With our new schema types & fields added, we need to publish our changes! We do that with Rover. Do you remember the command?

messages

rover subgraph publish APOLLO_GRAPH_REF --schema ./src/schema.graphql --name messages

Be sure to run this command from the root directory of your messages subgraph so that the path to the schema matches up. (And remember, you can access your APOLLO_GRAPH_REF from router/.env, or jump back to the README page in Studio.)

After running the command, you'll see the following message:

The host `localhost` is not routable via the public internet.
Continuing the publish will make this subgraph reachable in local environments only.
Would you still like to publish? [y/N]

Type in y to allow it. We're in workshop land and working in local environments for now!

Task!

I've published my schema changes.

Bonus! Check out the launch

Every new publish to Studio triggers a launch. It's the sequence of events that occur every time we change a component of our supergraph schema. A launch consists of a variety of checks and processes that ensure that our changes can be safely integrated into our supergraph.

Check out the Launches tab in the left-hand menu of Studio to see the results of your launch after publishing a change.

http://studio.apollographql.com

A screenshot of the Launches page in Studio, showing the sequence of checks that occur upon schema publish

Build (but don't run) the operation

In Studio Explorer, our schema changes enable us to write out a subscription operation. But we can't run it just yet! We haven't written any of the resolver logic to actually make the subscription work.

An operation we can BUILD but not yet RUN

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

Note: If you haven't already, be sure to add this operation to our Operation Collection so we can easily retrieve it later.

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.