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.

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!

1. Duplicate the subgraph-template folder in the root of the repo and rename the folder to subgraph-accounts.

2. Open up the index.js file. We'll need to fill in the port and subgraphName variables.

   The accounts subgraph should be running on port 4002.

   subgraph-accounts/index.js

   const port = 4002;
   const subgraphName = "accounts";

   Copy

   We'll fill in the dataSources later on!

3. In a new terminal, navigate to the subgraph-accounts directory.

   cd subgraph-accounts

   Copy

4. Install the packages.

   npm install

   Copy

5. Run the server using npm start.

   npm start

   Copy

You should now be able to query for the following using Sandbox at http://localhost:4002.

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 with id, name, profilePicture
• Host type with id, name, profilePicture and profileDescription
• Guest type with id, name, profilePicture
• Query.user
• Query.me
• Mutation.updateProfile
• The types used by the updateProfile mutation: UpdateProfileInput, UpdateProfileResponse and MutationResponse

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.