Overview
We're onto the last step in our migration plan: starting to split off subgraphs in small chunks! This last step is actually a big one, and we can break it down further into multiple steps. In this lesson, we will:
- Decide on what subgraphs will be part of our supergraph
- Set up another subgraph using a template
Future subgraphs
Deciding on where to start splitting off subgraphs can feel overwhelming. This is especially true if you have a large, complex graph, with multiple teams contributing and clients depending on its continued operation. We recommend keeping in mind a core principle of federation: incremental adoption. We'll break off the monolith subgraph's functionality one concern at a time.
After reviewing Airlock's architecture, we've decided on the following end goal: five subgraphs that are modeled after the services Airlock already has!
We'll keep applying the Strangler Fig approach and work on one subgraph at a time, breaking it off from the current monolith subgraph.
So where should we start? For Airlock, we're going to start with breaking off the accounts
subgraph. This subgraph will be responsible for all things related to accounts and users, login details, and user profiles. Additionally, we have a team dedicated to all things account-related that will manage this subgraph and its related services.
Note: Choosing which subgraph to start with first is dependent on your product and your teams. When adopting federation, we recommend that you identify a small but meaningful piece of your existing GraphQL implementation to isolate as the first subgraph.
In this course, we'll only cover breaking off the accounts
subgraph. The rest of the subgraphs will be left as an exercise for you in a separate lab!
✏️ Setting up the accounts
subgraph
Each subgraph we create will be located in its own folder prefixed with subgraph-
. We can see that there is already a folder in the starter repo called subgraph-template
. This subgraph-template
folder contains all of the files you’ll need to set up an Apollo Server subgraph with boilerplate code!
📂 subgraph-template┣ 📂 datasources┣ 📄 index.js (boilerplate subgraph starter code)┣ 📄 package.json┣ 📄 resolvers.js (contains a resolver for the `example` field)┗ 📄 schema.graphql (contains an `example` field to query)
Note: You can choose to create this subgraph from scratch (without using the template)! Otherwise, follow the steps below.
Duplicate the
subgraph-template
folder in the root of the repo and rename the folder tosubgraph-accounts
.Open up the
index.js
file. We'll need to fill in theport
andsubgraphName
variables.The
accounts
subgraph should be running on port4002
.subgraph-accounts/index.jsconst port = 4002;const subgraphName = "accounts";We'll fill in the
dataSources
later on!In a new terminal, navigate to the
subgraph-accounts
directory.cd subgraph-accountsInstall the packages.
npm installRun the server using
npm start
.npm start
You should now be able to query for the following using Sandbox at http://localhost:4002.
query {example # returns "Hello World"}
What's in the accounts
subgraph?
As we mentioned earlier, the accounts
subgraph will be responsible for all things related to accounts and users, login details, and user profiles.
Take a few moments to review the monolith/schema.graphql
file. What types and fields do you think we'll need to move from the monolith subgraph over to the accounts
subgraph? Write a list of what might belong to the accounts
subgraph. Then, keep on reading for our list!
Here's a list of types and their corresponding fields that would be appropriate for the accounts
subgraph to handle:
User
interface withid
,name
,profilePicture
Host
type withid
,name
,profilePicture
andprofileDescription
Guest
type withid
,name
,profilePicture
Query.user
Query.me
Mutation.updateProfile
- The types used by the
updateProfile
mutation:UpdateProfileInput
,UpdateProfileResponse
andMutationResponse
Remember that we can make these changes incrementally - we don't have to do it all at once! We can tackle the User
, Host
and Guest
types first, then the queries, and finally mutations.
"Wait, what about fields like Listing.host
, Booking.guest
and Review.author
? Shouldn't these be in the accounts
subgraph too because they deal with users and hosts and guests?"
Well, we could include them in the accounts
subgraph, but each of these types are more relevant to their corresponding domains (listings, bookings, and reviews, respectively). Let's keep them in the monolith subgraph. We'll reference the appropriate entities for those fields and use reference resolvers to resolve those fields, which we covered in Voyage I.
Key takeaways
- Starting with a plan of your end goal for your supergraph architecture is helpful in understanding where to start first.
- Keep in mind federation's core principle of incremental adoption. We'll start with one subgraph and take small action steps, one at a time.
Up next
We'll continue building our accounts
subgraph schema, starting with the User
interface.

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.