Why federation scales GraphQL - See It in Action

Building a Scalable GraphQL API with Federation

📖 Scenario: You are working on a growing e-commerce platform. As the platform expands, different teams manage different parts of the data: products, users, and orders. To keep the API fast and scalable, you want to use GraphQL federation to combine these separate services into one unified API.

🎯 Goal: Build a simple federated GraphQL setup with three services: products, users, and orders. Each service defines its own schema and shares key fields to enable federation. Then, create a gateway schema that combines them into one API.

📋 What You'll Learn

Create a GraphQL schema for the products service with a Product type and a products query.

Create a GraphQL schema for the users service with a User type and a users query.

Create a GraphQL schema for the orders service with an Order type and an orders query.

Add federation directives to share keys between services.

Create a gateway schema that composes the three services into one federated API.

💡 Why This Matters

🌍 Real World

Large companies use GraphQL federation to split their API into smaller, manageable services owned by different teams. This helps scale development and maintain performance.

💼 Career

Understanding GraphQL federation is valuable for backend developers and API architects working on scalable, modular APIs in modern web applications.

1

Create the Products Service Schema

Create a GraphQL schema for the products service. Define a Product type with fields id (ID!), name (String!), and price (Float!). Add a query products that returns a list of Product. Use the federation directive @key(fields: "id") on the Product type.

GraphQL

# Define the Product type and products query with federation key
# Your code here

Hint

Use @key(fields: "id") on the Product type to enable federation. Define the products query to return a list of products.

2

Create the Users Service Schema

Create a GraphQL schema for the users service. Define a User type with fields id (ID!), username (String!), and email (String!). Add a query users that returns a list of User. Use the federation directive @key(fields: "id") on the User type.

GraphQL

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

extend type Query {
  products: [Product]
}

# Define the User type and users query with federation key
# Your code here

Hint

Use @key(fields: "id") on the User type to enable federation. Define the users query to return a list of users.

3

Create the Orders Service Schema

Create a GraphQL schema for the orders service. Define an Order type with fields id (ID!), productId (ID!), userId (ID!), and quantity (Int!). Add a query orders that returns a list of Order. Use the federation directive @key(fields: "id") on the Order type.

GraphQL

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

extend type Query {
  products: [Product]
}

type User @key(fields: "id") {
  id: ID!
  username: String!
  email: String!
}

extend type Query {
  users: [User]
}

# Define the Order type and orders query with federation key
# Your code here

Hint

Use @key(fields: "id") on the Order type to enable federation. Define the orders query to return a list of orders.

4

Create the Gateway Schema to Compose Services

Create a gateway schema that composes the products, users, and orders services into one federated API. Use the Apollo Federation @apollo/gateway or similar tool to combine the schemas. The gateway should be able to resolve queries across services seamlessly.

GraphQL

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

extend type Query {
  products: [Product]
}

type User @key(fields: "id") {
  id: ID!
  username: String!
  email: String!
}

extend type Query {
  users: [User]
}

type Order @key(fields: "id") {
  id: ID!
  productId: ID!
  userId: ID!
  quantity: Int!
}

extend type Query {
  orders: [Order]
}

# Compose the three services into a federated gateway schema
# Your code here

Hint

Use Apollo Gateway's serviceList to list the three services by name and URL. This composes the federated schema.

Practice

1. What is the main benefit of using GraphQL federation in a large project?

easy

A. It removes the need for any backend services.

B. It makes the API slower by adding more layers.

C. It splits a big API into smaller parts for easier management.

D. It forces all teams to work on the same codebase.

Solution

1. Step 1: Understand federation purpose

   Federation breaks a large GraphQL API into smaller, manageable services.

2. Step 2: Identify the benefit

   This splitting helps teams work independently and manage parts easily.

3. Final Answer:

   It splits a big API into smaller parts for easier management. -> Option C

4. Quick Check:

   Federation = splits API for management [OK]

Hint: Federation means splitting big API into smaller parts [OK]

Common Mistakes:

• Thinking federation slows down the API
• Believing federation removes backend services
• Assuming all teams share one codebase

2. Which of the following is the correct way to define a federated service in GraphQL SDL?

easy

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

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

C. service Query { product(id: ID!): Product }

D. federation type Query { product(id: ID!): Product }

Solution

1. Step 1: Recall federation SDL syntax

   Federated services use extend type to add fields to shared types.

2. Step 2: Match correct syntax

   extend type Query { product(id: ID!): Product } uses extend type Query, which is correct for federation.

3. Final Answer:

   extend type Query { product(id: ID!): Product } -> Option B

4. Quick Check:

   Federation uses 'extend type' syntax [OK]

Hint: Federation adds fields with 'extend type' [OK]

Common Mistakes:

• Using 'type' instead of 'extend type' in federated services
• Using non-existent 'service' or 'federation' keywords
• Confusing base schema with extended schema

3. Given two federated services: Product service defines type Product { id: ID!, name: String } and Review service extends it with extend type Product { reviews: [Review] }. What will a query for { product(id: "1") { name reviews { body } } } return?

medium

A. Product name and list of reviews with their body fields.

B. Only product name, reviews field will be null.

C. Error because reviews field is not defined in Product service.

D. Empty result because federated services cannot combine fields.

Solution

1. Step 1: Understand federation field extension

   The Review service extends Product with reviews, so combined schema includes reviews.

2. Step 2: Query result combines data

   The query asks for product name and reviews body, which federation resolves from both services.

3. Final Answer:

   Product name and list of reviews with their body fields. -> Option A

4. Quick Check:

   Federation merges fields, query returns combined data [OK]

Hint: Federation merges extended fields into one response [OK]

Common Mistakes:

• Assuming extended fields are unavailable
• Expecting errors due to field extension
• Thinking federated services cannot combine data

4. A federated GraphQL setup has two services: User and Order. The User service defines type User { id: ID!, name: String }. The Order service tries to extend User with extend type User { orders: [Order] } but the gateway returns an error. What is the likely cause?

medium

A. User type is not marked with @key directive in User service.

B. Order service must define User type fully, not extend it.

C. Gateway does not support federation.

D. Orders field must be defined in User service, not Order service.

Solution

1. Step 1: Check federation key requirement

   Federation requires types extended across services to have a @key directive for identification.

2. Step 2: Identify missing @key

   User type lacks @key in User service, so gateway cannot resolve extensions.

3. Final Answer:

   User type is not marked with @key directive in User service. -> Option A

4. Quick Check:

   @key missing causes federation errors [OK]

Hint: Missing @key on base type breaks federation [OK]

Common Mistakes:

• Thinking extended types must be fully redefined
• Blaming gateway instead of schema directives
• Assuming fields must be in base service only

5. In a large company, multiple teams manage different parts of a GraphQL API using federation. Which of these practices best helps federation scale effectively?

hard

A. One team manages all services to ensure consistency.

B. All teams edit the same schema file to avoid conflicts.

C. Teams avoid using @key directives to keep schemas simple.

D. Each team owns a service with clear @key types and minimal overlap.

Solution

1. Step 1: Understand federation team ownership

   Federation scales by letting teams own services with clear boundaries and keys.

2. Step 2: Identify best practice

   Clear @key types and minimal overlap avoid conflicts and enable smooth composition.

3. Final Answer:

   Each team owns a service with clear @key types and minimal overlap. -> Option D

4. Quick Check:

   Team ownership + @key = scalable federation [OK]

Hint: Clear ownership and @key enable smooth federation scaling [OK]

Common Mistakes:

• Thinking one schema file for all teams scales well
• Avoiding @key directives breaks federation
• Centralizing all services under one team limits scaling