11. Finishing up the subgraph
5m

Overview

We're nearing the end! In this lesson, we will:

  • Run a few queries to test our changes
  • Publish the new accounts schema to

Testing our changes

We've got a few queries to test. We'll run each in our locally-running Explorer at http://localhost:4000 and make sure we get data back. We'll also take a peek at the to verify the correct are coming from the accounts .

Testing a root field

Testing a root field
query GetMyProfile {
  me {
    id
    name
    profilePicture
    ... on Host {
      profileDescription
    }
  }
}

Make sure your Headers are set to:

Authorization: Bearer user-1

You should get back:

Data response
{
  "data": {
    "me": {
      "id": "user-1",
      "name": "Eves",
      "profilePicture": "https://res.cloudinary.com/apollographql/image/upload/odyssey/airlock/user-1.png",
      "profileDescription": "I've been to 15 different planets and decided to make a home for myself and others in my favourites. Each planet and location has its own distinct environment, so read the description carefully. I have equipped them all with the necessary amenities."
    }
  }
}

And the should show these types and coming from the accounts !

studio.apollographql.com

Query plan for me field host

Testing a listing's host

Testing the entity representations
query GetListingHost {
  listing(id: "listing-1") {
    host {
      name
      profilePicture
      profileDescription
    }
  }
}

You should get back:

Data response
{
  "data": {
    "listing": {
      "host": {
        "name": "Eves",
        "profilePicture": "https://res.cloudinary.com/apollographql/image/upload/odyssey/airlock/user-1.png",
        "profileDescription": "I've been to 15 different planets and decided to make a home for myself and others in my favourites. Each planet and location has its own distinct environment, so read the description carefully. I have equipped them all with the necessary amenities."
      }
    }
  }
}

Testing a review's author

query GetListingReviewsAuthor {
  listing(id: "listing-1") {
    reviews {
      author {
        id
        name
      }
    }
  }
}

The should show the listing and reviews coming from the monolith , and the author coming from the accounts !

studio.apollographql.com

Query plan for review author

Feel free to play around with some other queries and examine the corresponding !

Publishing our subgraph schemas

Ready to bring these changes to our ? Let's go, you know the drill!

In a terminal window, from the root directory, run the following:

rover subgraph publish <APOLLO_GRAPH_REF> \
  --schema ./subgraph-accounts/schema.graphql \
  --name accounts

Remember to replace the <APOLLO_GRAPH_REF> value with your own!

Testing our changes

Feel free to run the same as in the earlier section (refer back to Lesson 5 where we ran the locally) to make sure everything's working correctly!

Let's head over to the Schema page and scroll down the list to find the me and user . We can see that the accounts is now listed together with the monolith column.

studio.apollographql.com

Query plan for listing host

Returning to the client

We should still have our client application running on port 3000. If not, navigate to the client directory and run npm start.

Returning to the app, however, we see an error on the homepage!

http://localhost:3000
The homepage of Airlock's client app, displaying a failed to fetch error

When we check out the errors in the console, we'll find a message that might be familiar from the first course in this series.

Access to fetch at 'http://localhost:4000' from origin 'http://localhost:3000'
has been blocked by CORS policy

In Voyage I, we saw how to modify our 's config.yaml file to allow requests from a client to reach our . Let's add the CORS options to our config.yaml file now to permit our client app at http://localhost:3000 to talk to our .

Note: You can read more about CORS (and why it's important) in the Apollo documentation.

CORS configuration

Open up router-config.yaml in the server's router directory. At the bottom of the file, we'll add the following configuration:

router/router-config.yaml
include_subgraph_errors:
  all: true # Propagate errors from all subgraphs
headers:
  all:
    request:
      - propagate:
          named: "Authorization"
cors:
  origins:
    - http://localhost:3000 # Allows any locally-running client to run against your Router
    - https://studio.apollographql.com # Allows Studio to still run queries against your Router

These rules will continue to allow requests from Studio to reach our , and will now also permit requests from our frontend app.

Navigate to the terminal where your is currently running. Stop the server process, and then restart it. When we refresh http://localhost:3000, we'll see that we're getting data back!

http://localhost:3000
The homepage of Airlock's client app, now displaying data about listings

Over time, as we monitor the performance of the accounts and deem it successful, we'll reach a point where we can safely remove the in the monolith . Then, we can remove the @override entirely!

Note: If you used progressive override, you would slowly increase the traffic going into the overriding until it reached 100%. At that point, you can safely remove the in the other subgraph.

Key takeaways

  • Splitting off incrementally enables teams to reap the benefits of federation sooner.
  • Use the @override to migrate safely between .
  • The configuration file takes an option to define a CORS policy, which allows the origins you specify to communicate with your router.

Checking in with the Airlock team

Congratulations, we're on our way to a complete ! Remember our monolithic monster at the beginning of the course that teams were intimidated by and struggling with? Let's see what they have to say about it now:

  • 👩🏽‍🚀 The Accounts Team says:

    "It's great being able to focus on our own responsibilities! We're much faster at making changes and pushing updates compared to before. Excited for the new features incoming!"

  • 👩🏽‍🏫 The Listings Team says:

    "With the accounts completed, the monolith schema is a little more manageable. We're excited to get our team's domain responsibilities on our own subgraph too! The heavy lifting was already done for us with the setup and the first subgraph out of the way, so we can use that as a blueprint to get our own listings started."

An illustration of the monolith monster transforming into a supergraph.

Amazing, we've made big leaps and improvements to the developer experience that will set us up for great things to come in Airlock's future!

Conclusion

In this course, we learned the process of how to migrate from a monolith to a . We first converted the original graph into one large , which we published to . Then, we installed and ran a using the same URL as the original graph, so that the client wouldn't need any changes.

We learned how to prepare and plan for splitting by identifying , grouping entities, and sorting out which types and belong where. We started with the accounts , learning how to use a stub subgraph to get started. Then we used the @override to safely migrate over from the monolith to the accounts .

We've still got four more to go before our is complete, and you have all the tools you need to tackle those!

In the next course of the Voyage series, we'll take a look at how to bring Airlock to production and how to use features like , , and observability. See you in Voyage III: Federation in Production!

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.