Why federation scales GraphQL - Quick Recap

Recall & Review

beginner

What is GraphQL federation?

GraphQL federation is a way to combine multiple GraphQL services into one unified graph, allowing them to work together as a single API.

beginner

How does federation help scale GraphQL APIs?

Federation helps scale GraphQL by letting teams build and maintain separate services independently, which then combine into one graph, making it easier to grow and manage large APIs.

intermediate

Why is dividing a GraphQL API into smaller services beneficial?

Dividing a GraphQL API into smaller services allows teams to work on different parts without conflicts, speeds up development, and improves reliability by isolating issues.

intermediate

What role does the gateway play in GraphQL federation?

The gateway acts like a traffic controller that receives client requests and routes them to the right service, then combines the results into one response.

beginner

How does federation improve team collaboration?

Federation allows different teams to own and update their parts of the API independently, reducing coordination overhead and speeding up changes.

What does GraphQL federation primarily enable?

A Encrypting GraphQL queries

B Replacing REST APIs with GraphQL

C Caching GraphQL responses

D Combining multiple GraphQL services into one API

Federation allows multiple GraphQL services to work together as a single API.

In federation, what is the main purpose of the gateway?

A To route requests to the correct service and combine responses

B To store data

C To authenticate users

D To generate GraphQL schemas

The gateway routes client requests to the right services and merges their responses.

How does federation help when multiple teams work on a GraphQL API?

A It allows teams to own separate services independently

B It forces all teams to work on the same codebase

C It limits the number of queries teams can write

D It merges all team code into one file

Federation lets teams manage their own services, improving collaboration and reducing conflicts.

Which of these is NOT a benefit of GraphQL federation?

A Improved API scalability

B Independent service deployment

C Automatic database backups

D Faster development cycles

Federation does not handle database backups; it focuses on API composition and scaling.

What happens if one federated service fails?

A The entire API stops working

B Only the part of the API from that service is affected

C The gateway automatically fixes the service

D The client receives no response

Failure in one service affects only its part, improving overall API reliability.

Explain in your own words why federation helps GraphQL scale better.

Think about how dividing work and combining results helps big projects.

Describe the role of the gateway in a federated GraphQL architecture.

Imagine the gateway as a traffic controller for API requests.

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