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.