Why federation scales GraphQL - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does federation improve GraphQL scalability?

Which of the following best explains why federation helps GraphQL scale better?

A It splits a large GraphQL schema into smaller services, allowing independent development and scaling.

B It caches all GraphQL queries on the client side to reduce server load.

C It merges all backend databases into one to simplify data retrieval.

D It converts GraphQL queries into SQL queries automatically for faster database access.

💡 Hint

Think about how dividing work among smaller parts can help handle more requests.

Federation breaks a big GraphQL schema into smaller, manageable services. Each service can be developed and scaled independently, improving overall scalability.

❓ query_result

intermediate

Result of federated GraphQL query

Given two federated services: Users and Products, what will be the result of this query? { user(id: "1") { name purchasedProducts { name } } } Assuming user 1 has purchased two products: 'Book' and 'Pen'.

A { "data": { "user": { "name": "Alice", "purchasedProducts": null } } }

B { "data": { "user": { "name": "Alice", "purchasedProducts": [{ "name": "Book" }, { "name": "Pen" }] } } }

C { "errors": [{ "message": "Field 'purchasedProducts' not found" }] }

D { "data": { "user": null } }

💡 Hint

Federation allows combining data from multiple services in one query.

Federation merges data from Users and Products services, so the query returns user info plus purchased products.

📝 Syntax

advanced

Identify the syntax error in this federation SDL

Which option contains the correct syntax for extending a type in a federated GraphQL schema? Given this partial schema: extend type Product @key(fields: "id") { id: ID! @external price: Float } Which option fixes the syntax error?

A

extend type Product @key(fields: "id") {
  id: ID @external
  price: Float
}

B

extend type Product @key(fields: id) {
  id: ID! @external
  price: Float
}

C

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

D

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

💡 Hint

Look carefully at the placement of keywords and quotes.

Option C uses correct syntax: 'extend type', '@key' with quoted fields, and 'id' marked as non-null with @external.

❓ optimization

advanced

Optimizing federated GraphQL queries

Which approach best optimizes performance in a federated GraphQL setup when multiple services are involved?

A Batch requests to services and minimize nested queries to reduce network overhead.

B Use only one service to handle all queries to avoid federation complexity.

C Send separate queries to each service for every client request to ensure fresh data.

D Disable caching to always get the latest data from each service.

💡 Hint

Think about reducing the number of network calls and data fetching.

Batching requests and minimizing nested queries reduce network calls and improve response times in federated systems.

🔧 Debug

expert

Debugging a federation key mismatch error

You have two federated services: Users and Orders. Users service defines: type User @key(fields: "id") { id: ID! name: String } Orders service defines: type User @key(fields: "userId") { userId: ID! orders: [Order] } When querying user orders, you get an error about key mismatch. What is the cause?

A The Orders service is missing the @external directive on 'userId'.

B The Orders service must use 'id' as the field name instead of 'userId' without changing the key.

C The User type must not be defined in more than one service.

D The key fields differ between services: 'id' vs 'userId', causing federation to fail to match entities.

💡 Hint

Check if the key fields used to identify the same type are consistent across services.

Federation requires the @key fields to match exactly across services to correctly identify the same entity.

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