Apollo Federation concepts in GraphQL - Step-by-Step Execution

Concept Flow - Apollo Federation concepts

Define Subgraphs

↓

Add @key to types

↓

Implement resolvers

↓

Compose Supergraph

↓

Deploy Gateway

↓

Query Gateway

↓

Gateway delegates to Subgraphs

↓

Collect and merge responses

↓

Return combined result to client

Apollo Federation lets you build a single GraphQL API from multiple services called subgraphs. The gateway composes them and handles queries by delegating to subgraphs.

Execution Sample

GraphQL

type Product @key(fields: "id") {
  id: ID!
  name: String
}

extend type Query {
  product(id: ID!): Product
}

Defines a Product type with a key field 'id' in a subgraph, and extends Query to fetch a product by id.

Execution Table

Step	Action	Details	Result
1	Define Subgraph schema	Product type with @key on 'id'	Subgraph schema ready
2	Implement resolver	Resolver for Query.product(id)	Subgraph can resolve product by id
3	Compose Supergraph	Gateway composes subgraphs using their schemas and @key	Supergraph schema created
4	Deploy Gateway	Gateway runs with composed schema	Gateway ready to accept queries
5	Client sends query	Query for product with id=1	Gateway receives query
6	Gateway delegates	Gateway sends product(id:1) query to subgraph	Subgraph receives query
7	Subgraph resolves	Subgraph returns product data	Product data returned to gateway
8	Gateway merges	Gateway merges responses if multiple subgraphs	Combined result ready
9	Gateway responds	Gateway sends combined result to client	Client receives product data
10	Exit	Query completed	Execution ends

💡 Query completed after gateway merges subgraph responses and returns data to client

Variable Tracker

Variable	Start	After Step 3	After Step 6	After Step 7	Final
Subgraph Schema	Empty	Product type with @key	Same	Same	Same
Gateway Schema	Empty	Composed supergraph schema	Same	Same	Same
Client Query	None	None	product(id:1)	Same	Same
Subgraph Response	None	None	None	{id:1, name:'Table'}	{id:1, name:'Table'}
Gateway Response	None	None	None	None	{id:1, name:'Table'}

Key Moments - 3 Insights

Why do we add @key to types in subgraphs?

The @key directive tells Apollo Federation which field uniquely identifies an object so the gateway can correctly merge data from different subgraphs. See execution_table step 1 and 3.

How does the gateway know which subgraph to ask for data?

The gateway uses the composed supergraph schema and the @key fields to route parts of the query to the correct subgraph. See execution_table step 6.

What happens if multiple subgraphs provide parts of the same type?

The gateway merges the responses from subgraphs based on the @key fields to form a complete object before sending to the client. See execution_table step 8.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the gateway compose the supergraph schema?

A Step 5

B Step 3

C Step 7

D Step 9

💡 Hint

Check the 'Action' column for 'Compose Supergraph' in execution_table

According to variable_tracker, what is the value of 'Subgraph Response' after Step 7?

A Empty

B Composed schema

C Product data {id:1, name:'Table'}

D Client query

💡 Hint

Look at the 'Subgraph Response' row and the 'After Step 7' column in variable_tracker

If the @key directive was missing on the Product type, what would likely happen?

A Gateway would fail to merge data correctly

B Gateway would ignore the subgraph

C Client would get an error immediately

D Subgraph would not start

💡 Hint

Refer to key_moments about the importance of @key directive

Concept Snapshot

Apollo Federation lets you combine multiple GraphQL services (subgraphs) into one API.
Use @key on types to identify unique objects.
Gateway composes subgraphs into a supergraph schema.
Gateway routes queries to subgraphs and merges results.
Clients query the gateway as if it is a single GraphQL API.

Full Transcript

Apollo Federation is a way to build a single GraphQL API from many smaller services called subgraphs. Each subgraph defines parts of the schema and marks unique types with @key. The gateway composes these subgraphs into a supergraph schema. When a client sends a query to the gateway, it breaks the query into parts and sends them to the right subgraphs. The subgraphs respond with data, and the gateway merges these responses into one result. This result is sent back to the client. This process allows teams to work independently on different parts of the API while providing a unified experience to clients.