7. How the router resolves data


So far, we've mainly been focused on our s. Now it's time!

We know that the uses the to resolve incoming GraphQL s from the client. But how exactly does that process work?

In this lesson, we will:

  • Trace the journey of a client request through the
  • Describe how the creates query plans to resolve GraphQL s across multiple s

The journey of a GraphQL operation through the supergraph

Let's start at the beginning: from the client request.

Step 1: The client request

First, the client sends a GraphQL to the . The client has no clue which s belong to which s—or even that there are subgraphs at all!

Step 1: The client sends a GraphQL operation to the router

Step 2: Building a query plan

The looks at the s in the and uses the to figure out which s are responsible for resolving each field.

The router uses the supergraph schema

It uses this information to build a query plan, a list of smaller GraphQL s to execute on the s. The query plan also specifies the order in which the subgraph operations need to run.

The router builds a query plan

Step 3: Executing the query plan

Next, the carries out the query plan by sending the smaller GraphQL s to each of the s it needs data from.

The router carries out the query plan

The s resolve the s the same way as any other GraphQL server: they use their s and s to retrieve and populate the requested data.

The subgraphs resolve the operations

Step 4: The subgraph responses

The s send back the requested data to the , and then the router combines all those responses into a single JSON object.

The subgraphs send back the requested data to the router

Step 5: Sending data back to the client

Finally, the sends the final JSON object back to the client. And that's the end of our 's journey!

The router sends the final JSON object back to the client


Here's the entire journey of a GraphQL through the , summarized in a single diagram:

federated graph query animations


Which of the following statements are true?

Key takeaways

  • The uses the to create a query plan for the incoming GraphQL . The query plan is a list of smaller operations the can execute on different s to fully resolve the incoming operation.
  • The carries out the query plan by executing the list of s on the appropriate s.
  • The combines all the responses from the s into a single JSON object, which it sends back to the client.

Up next

Coming up next, we're going to configure the to poll Apollo Uplink for our , and we'll finally begin querying our supergraph!


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.