6. Subgraph planning
4m

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 . 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!

A diagram showing the router at the top. The router splits off into five different subgraphs: accounts, listings, bookings, reviews and payments. Each subgraph is connected to its corresponding service API.

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.

  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 s.

    The accounts subgraph should be running on port 4002.

    subgraph-accounts/index.js
    const port = 4002;
    const subgraphName = "accounts";

    We'll fill in the dataSources later on!

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

    cd subgraph-accounts

  4. Install the packages.

    npm install

  5. Run the server using npm start.

    npm start
Task!

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 s 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 s 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
Diagram to display the fields above

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 s.

"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 s and use reference resolvers to resolve those s, 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 , starting with the User interface.

Diagram of the migration plan step 3. Step 3 was incrementally split off our subgraphs and publish them to the registry
Previous
Next