In a federated architecture, each microservice (subgraph) owns part of the schema — e.g., UserService owns User types, OrderService owns Order types. The router composes these into a unified supergraph for clients.
2 / 15
The router (or gateway) in a federated GraphQL setup:
The router is the single entry point for clients. It receives a query, uses the composed supergraph to plan which subgraphs to call (and in what order), executes the query plan, and assembles the final response.
3 / 15
The @key directive in Apollo Federation marks:
The @key directive tells Federation that this type can be uniquely identified by the specified field(s). Other subgraphs can extend the type and the router can use the key to fetch the entity from the owning subgraph.
4 / 15
Schema composition in GraphQL Federation means:
Composition takes all subgraph schemas, validates that cross-schema references are consistent (e.g., @key fields match, @external fields exist), and produces the supergraph schema that the router uses for query planning.
5 / 15
What is the main advantage of GraphQL Federation over schema stitching?
Schema stitching required a central gateway team to stitch schemas and handle cross-service resolution manually. Federation pushes ownership to subgraph teams — each team declares their schema and the composition is handled automatically.
6 / 15
During a code review of the API Gateway configuration for our new federated GraphQL setup, Sarah from the Backend team comments: 'I'm seeing that the @key directive on the `User` type in the `users` subgraph is pointing to the wrong ID field. It's currently using `userId`, but we agreed during the architecture discussions that we should use `id`. Can you double-check this and update it?'. What does Sarah's comment primarily relate to within the context of Apollo Federation?
Sarah's comment focuses on the precise configuration of schema mapping—how the gateway understands and relates to different subgraph definitions. The @key directive is crucial for this process; it tells the gateway which field in one schema corresponds to a resource in another. The other options represent broader aspects of GraphQL Federation, but aren't directly addressed by her specific observation.
7 / 15
In a Slack channel discussing the implementation of our federated GraphQL API, David asks: 'We're seeing some latency spikes when querying across subgraphs. I've been investigating and found that the gateway is performing multiple calls to the `Product` subgraph for each query. Is this normal behavior or should we be doing something differently?'. What is the most likely reason for David's observation?
While a well-designed gateway *might* combine data in some scenarios, David's description points to a fundamental aspect of federation: each subgraph is treated as an independent resource. The gateway typically resolves these independently and returns them separately unless specifically designed for aggregation – which isn't the default behavior or assumed without explicit configuration. This can lead to increased latency if not managed correctly.
8 / 15
You're drafting a PR description for a change that introduces schema composition using GraphQL Federation. You want to clearly articulate the benefit. Which of the following statements best summarizes this advantage?
The core benefit of schema composition (and therefore federation) is that clients interact with subgraphs as if they were a single, unified GraphQL API. This abstraction hides the underlying complexities and structural differences of each subgraph, simplifying client development significantly. Schema stitching, in contrast, requires the client to understand how all schemas are interconnected.
9 / 15
During a standup meeting, Maria from the Frontend team asks: 'I'm having trouble understanding how to use the gateway's API to filter data across subgraphs. Is there a specific way I should be structuring my queries to ensure efficient retrieval of related information?'. What is a key consideration when designing GraphQL Federation queries?
Effective schema composition relies on subgraphs being designed with appropriate data granularity. This means that each subgraph should expose only the necessary fields and relationships to avoid unnecessary data transfer during federation queries. A poorly designed subgraph can lead to inefficient query performance and increased latency when combined across multiple services.
10 / 15
You're reviewing a GraphQL Federation implementation and notice the gateway is configured with several layers of caching. A senior developer explains: 'We're using this layered approach to improve performance by storing responses from subgraphs at different levels – client-side, gateway-side, and subgraph-side'. What is the primary motivation behind this multi-layered caching strategy in a federated GraphQL setup?
The core goal of multi-layered caching in a federated environment is to mitigate latency and reduce load on individual subgraphs. By storing frequently accessed data at multiple levels (client, gateway, subgraph), the gateway can serve responses directly from the cache without requiring repeated calls to the underlying services. This significantly improves query performance.
11 / 15
During a code review of the API Gateway configuration for our new federated GraphQL setup, Sarah from the Backend team comments: 'I'm seeing that the @key directive on the `User` type in the `users` subgraph is pointing to the wrong ID field. It's currently using `userId`, but we agreed during the architecture discussions that we should use `id`. Can you double-check this and update it?'. What does Sarah's comment primarily relate to within the context of Apollo Federation?
Sarah's comment focuses on the precise configuration of schema mapping—how the gateway understands and relates to different subgraph definitions. The @key directive is crucial for this process; it tells the gateway which field in one schema corresponds to a resource in another. The other options represent broader aspects of GraphQL Federation, but aren't directly addressed by her specific observation.
12 / 15
In a Slack channel discussing the implementation of our federated GraphQL API, David asks: 'We're seeing some latency spikes when querying across subgraphs. I've been investigating and found that the gateway is performing multiple calls to the `Product` subgraph for each query. Is this normal behavior or should we be doing something differently?'. What is the most likely reason for David's observation?
While a well-designed gateway *might* combine data in some scenarios, David's description points to a fundamental aspect of federation: each subgraph is treated as an independent resource. The gateway typically resolves these independently and returns them separately unless specifically designed for aggregation – which isn't the default behavior or assumed without explicit configuration. This can lead to increased latency if not managed correctly.
13 / 15
You're drafting a PR description for a change that introduces schema composition using GraphQL Federation. You want to clearly articulate the benefit. Which of the following statements best summarizes this advantage?
The core benefit of schema composition (and therefore federation) is that clients interact with subgraphs as if they were a single, unified GraphQL API. This abstraction hides the underlying complexities and structural differences of each subgraph, simplifying client development significantly. Schema stitching, in contrast, requires the client to understand how all schemas are interconnected.
14 / 15
During a standup meeting, Maria from the Frontend team asks: 'I'm having trouble understanding how to use the gateway's API to filter data across subgraphs. Is there a specific way I should be structuring my queries to ensure efficient retrieval of related information?'. What is a key consideration when designing GraphQL Federation queries?
Effective schema composition relies on subgraphs being designed with appropriate data granularity. This means that each subgraph should expose only the necessary fields and relationships to avoid unnecessary data transfer during federation queries. A poorly designed subgraph can lead to inefficient query performance and increased latency when combined across multiple services.
15 / 15
You're reviewing a GraphQL Federation implementation and notice the gateway is configured with several layers of caching. A senior developer explains: 'We're using this layered approach to improve performance by storing responses from subgraphs at different levels – client-side, gateway-side, and subgraph-side'. What is the primary motivation behind this multi-layered caching strategy in a federated GraphQL setup?
The core goal of multi-layered caching in a federated environment is to mitigate latency and reduce load on individual subgraphs. By storing frequently accessed data at multiple levels (client, gateway, subgraph), the gateway can serve responses directly from the cache without requiring repeated calls to the underlying services. This significantly improves query performance.
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more GraphQL & API Gateway Language exercises?
Browse the full GraphQL & API Gateway Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.