6. Subgraph planning
4m

Overview

We're onto the last step in our migration plan: starting to split off 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 will be part of our
  • Set up another using a template

Future subgraphs

Deciding on where to start splitting off 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 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 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 . This subgraph will be responsible for all things related to accounts and users, login details, and user profiles. Additionally, we have a team to all things account-related that will manage this subgraph and its related services.

Note: Choosing which 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 implementation to isolate as the first subgraph.

In this course, we'll only cover breaking off the accounts . The rest of the subgraphs will be left as an exercise for you in a separate lab!

✏️ Setting up the accounts subgraph

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

    The accounts 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 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 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 do you think we'll need to move from the monolith over to the accounts ? Write a list of what might belong to the accounts . Then, keep on reading for our list!

Here's a list of types and their corresponding that would be appropriate for the accounts 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 : 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 .

"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 , 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 and use reference resolvers to resolve those , which we covered in Voyage I.

Key takeaways

  • Starting with a plan of your end goal for your architecture is helpful in understanding where to start first.
  • Keep in mind federation's core principle of incremental adoption. We'll start with one and take small action steps, one at a time.

Up next

We'll continue building our accounts , 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

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.