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.

Practice

1. What is the primary purpose of Apollo Federation in GraphQL?

easy

A. To replace REST APIs with GraphQL

B. To create a new database schema

C. To combine multiple GraphQL services into a single API

D. To optimize SQL queries automatically

Solution

1. Step 1: Understand Apollo Federation's role

   Apollo Federation is designed to combine multiple GraphQL services into one unified API.

2. Step 2: Compare options

   Options B, C, and D describe unrelated tasks. Only To combine multiple GraphQL services into a single API correctly describes Apollo Federation's purpose.

3. Final Answer:

   To combine multiple GraphQL services into a single API -> Option C

4. Quick Check:

   Apollo Federation = combine services [OK]

Hint: Federation = combining services into one API [OK]

Common Mistakes:

• Confusing Federation with database schema design
• Thinking Federation replaces REST APIs directly
• Assuming Federation optimizes SQL queries

2. Which of the following is the correct syntax to mark a unique identifier for an entity in Apollo Federation?

easy

A. type User @unique(fields: "id") { id: ID! name: String }

B. type User @key(fields: "id") { id: ID! name: String }

C. type User @id(fields: "id") { id: ID! name: String }

D. type User @primary(fields: "id") { id: ID! name: String }

Solution

1. Step 1: Recall the directive for unique identifiers

   In Apollo Federation, the @key directive marks the unique identifier fields for an entity.

2. Step 2: Check syntax correctness

   type User @key(fields: "id") { id: ID! name: String } uses @key(fields: "id"), which is the correct syntax. Other options use incorrect directives.

3. Final Answer:

   type User @key(fields: "id") { id: ID! name: String } -> Option B

4. Quick Check:

   @key directive = unique ID marker [OK]

Hint: Use @key to mark unique entity IDs [OK]

Common Mistakes:

• Using @unique or @id instead of @key
• Missing quotes around field names
• Confusing @key with database primary key syntax

3. Given the following schema in a federated service:

extend type Product @key(fields: "upc") { upc: String @external price: Int }

What does the extend type keyword do here?

medium

A. Adds the price field to an existing Product type from another service

B. Removes the upc field from Product type

C. Defines a new Product type with fields upc and price

D. Creates a local copy of Product type without federation

Solution

1. Step 1: Understand 'extend type' in Apollo Federation

   The extend type keyword adds fields to a type defined in another service.

2. Step 2: Analyze the example

   The Product type is extended to add the price field, while upc is marked as external, meaning it comes from the original service.

3. Final Answer:

   Adds the price field to an existing Product type from another service -> Option A

4. Quick Check:

   extend type = add fields to existing type [OK]

Hint: extend type adds fields to existing types [OK]

Common Mistakes:

• Thinking extend type creates a new type
• Confusing @external with local fields
• Assuming extend type removes fields

4. Identify the error in this federated schema snippet:

type Review @key(fields: "id") { id: ID! body: String author: User }

Assuming User is defined in another service, what is missing?

medium

A. The User type should be imported explicitly

B. The author field should be marked with @external

C. The author field should be marked with @provides or @requires

D. The Review type should use extend keyword

Solution

1. Step 1: Understand referencing external entities

   In Apollo Federation, to reference an entity type like User from another service, the schema must explicitly extend that type with its @key directive: extend type User @key(fields: "id") { id: ID! }.

2. Step 2: Analyze the snippet

   The Review type references User via author: User but lacks the required extend declaration for User, which is necessary for the gateway to know this service can resolve User.

3. Final Answer:

   The User type should be imported explicitly -> Option A

4. Quick Check:

   Reference entities -> extend type @key [OK]

Hint: Extend referenced entities with @key [OK]

Common Mistakes:

• Marking author field with @provides or @requires
• Marking author field as @external
• Using extend keyword for Review type

5. You have two services: Accounts defining type User @key(fields: "id") { id: ID! name: String } and Reviews extending User with extend type User @key(fields: "id") { id: ID! reviews: [Review] }. How does Apollo Federation resolve the User entity across these services?

hard

A. It requires manual merging of User data in the gateway

B. It duplicates User types separately in each service

C. It ignores the extend type and uses only the Accounts User type

D. It merges User types by matching the @key field 'id' across services

Solution

1. Step 1: Understand @key usage in federation

   The @key directive identifies the unique field used to match entities across services.

2. Step 2: Analyze entity resolution

   Apollo Federation merges types with the same @key field by matching their unique identifiers, combining fields from both services.

3. Final Answer:

   It merges User types by matching the @key field 'id' across services -> Option D

4. Quick Check:

   @key fields unify entities across services [OK]

Hint: Entities merge by matching @key fields [OK]

Common Mistakes:

• Thinking types are duplicated instead of merged
• Assuming extend type is ignored
• Believing manual merging is required