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

Planning and preparation

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.

To help with our planning, we'll break it down into a few steps:

1. Identify entities
2. Identify subgraphs
3. Decide which entities to migrate first

1. Identify entities

An entity is an object type with fields split between multiple subgraphs. It's the building block of our federated graph. Each subgraph is responsible for resolving only the fields it contributes to an entity, and each entity instance is uniquely identifiable with a primary key field.

Take a few moments to review the monolith/schema.graphql file and identify which object types should be marked as entities.

When you're ready, review the section below to compare your list against ours!

Did you get them all?

What about other object types? For example, Amenity is an object type but it's not included in our list, even though it's uniquely identifiable (with each Amenity having its own id field). The Amenity type acts more like an attribute attached to a Listing, and it most likely won't have any fields split off across subgraphs.

What about the User interface? We could make it an entity, but the fields in the User interface are all related to a user only. If it had additional fields we could split off into other subgraphs, we might consider making it an entity (and we still could in the future!).

Additionally, we cannot mark the following types as entities: enums (like AmenityCategory), inputs (like SearchListingsInput), and mutation responses (like CreateListingResponse).

2. Identify subgraphs

We should now have a better idea of what subgraphs we'll create to manage different domain responsibilities. We might also think about our organization's team structure, the services or data sources that currently exist, and future features we want to build.

Again, take a moment to think about how you might design the subgraphs for Airlock. When you're ready, review the section below to compare your list against ours!

For Airlock, we've decided to create 5 subgraphs. In the first lesson, we were introduced to the Accounts Team and the Listings Team, each with their own set of responsibilities, so it makes sense to give them their own subgraphs. We could have merged all booking functionality into the listings subgraph; and same thing with reviews. But they both feel like big separate domains that could be handled within their own subgraphs too. Payments are typically handled by a third-party service, so giving that its own subgraph also makes sense.

If your list is slightly different, that's okay! There's no single correct way to design a schema. You might choose different names, or have a more granular scope. As long as you're able to articulate your reasoning behind your decisions, you're good to go! And remember you can always evolve and iterate on your schema.

Here's what the ideal Airlock federated architecture will look like when all the migrations are complete:

We'll work on one subgraph at a time, breaking it off from the current monolith subgraph.

3. Decide which entities to migrate first

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.

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.

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!

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've have our plan in place, now let's get to the implementation!