Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Building a Simple Apollo Federation Setup
📖 Scenario: You are working on a project where multiple teams manage different parts of a product catalog. Each team has its own GraphQL service. You want to combine these services into one unified graph so clients can query all product information easily.
🎯 Goal: Build a basic Apollo Federation setup with two services: products and reviews. Each service defines its own GraphQL schema. Then create a gateway schema that composes these services into one federated graph.
📋 What You'll Learn
Create a products service schema with a Product type having id and name fields
Create a reviews service schema with a Review type and extend the Product type to add reviews field
Use Apollo Federation directives like @key and @extends correctly
Create a gateway schema that composes the two services into one federated graph
💡 Why This Matters
🌍 Real World
Large companies often split their GraphQL APIs into multiple services owned by different teams. Apollo Federation helps combine these into one seamless API for clients.
💼 Career
Understanding Apollo Federation is valuable for backend developers working with GraphQL in microservice architectures.
Progress0 / 4 steps
1
Create the Products Service Schema
Create a GraphQL schema string called productsTypeDefs that defines a Product type with fields id (ID!) and name (String!). Add the Apollo Federation directive @key(fields: "id") to the Product type.
GraphQL
Hint
Use backticks to create a multi-line string. The @key directive marks the primary key field for federation.
2
Create the Reviews Service Schema
Create a GraphQL schema string called reviewsTypeDefs that defines a Review type with fields id (ID!) and content (String!). Extend the Product type with @extends and @key(fields: "id") directives, adding a reviews field that returns a list of Review.
GraphQL
Hint
Use extend type to add fields to Product in the reviews service. Mark id as @external because it is owned by the products service.
3
Create the Apollo Gateway Setup
Create a variable called gateway that initializes an ApolloGateway instance with a serviceList containing two services: one named products with URL http://localhost:4001/graphql and one named reviews with URL http://localhost:4002/graphql.
GraphQL
Hint
Use new ApolloGateway({ serviceList: [...] }) to configure the gateway with the two services.
4
Complete the Apollo Server Setup with Gateway
Create a variable called server that initializes an ApolloServer instance using the gateway variable. Set subscriptions to false in the server options.
GraphQL
Hint
Pass the gateway variable to the ApolloServer constructor and disable subscriptions.
Practice
(1/5)
1. What is the primary purpose of Apollo Federation in GraphQL?
easy
A. To replace REST APIs with GraphQL
B. To create a new database schema
C. To combine multiple GraphQL services into a single API
D. To optimize SQL queries automatically
Solution
Step 1: Understand Apollo Federation's role
Apollo Federation is designed to combine multiple GraphQL services into one unified API.
Step 2: Compare options
Options B, C, and D describe unrelated tasks. Only To combine multiple GraphQL services into a single API correctly describes Apollo Federation's purpose.
Final Answer:
To combine multiple GraphQL services into a single API -> Option C
Quick Check:
Apollo Federation = combine services [OK]
Hint: Federation = combining services into one API [OK]
Common Mistakes:
Confusing Federation with database schema design
Thinking Federation replaces REST APIs directly
Assuming Federation optimizes SQL queries
2. Which of the following is the correct syntax to mark a unique identifier for an entity in Apollo Federation?
easy
A. type User @unique(fields: "id") { id: ID! name: String }
B. type User @key(fields: "id") { id: ID! name: String }
C. type User @id(fields: "id") { id: ID! name: String }
D. type User @primary(fields: "id") { id: ID! name: String }
Solution
Step 1: Recall the directive for unique identifiers
In Apollo Federation, the @key directive marks the unique identifier fields for an entity.
Step 2: Check syntax correctness
type User @key(fields: "id") { id: ID! name: String } uses @key(fields: "id"), which is the correct syntax. Other options use incorrect directives.
Final Answer:
type User @key(fields: "id") { id: ID! name: String } -> Option B
Quick Check:
@key directive = unique ID marker [OK]
Hint: Use @key to mark unique entity IDs [OK]
Common Mistakes:
Using @unique or @id instead of @key
Missing quotes around field names
Confusing @key with database primary key syntax
3. Given the following schema in a federated service:
extend type Product @key(fields: "upc") { upc: String @external price: Int }
What does the extend type keyword do here?
medium
A. Adds the price field to an existing Product type from another service
B. Removes the upc field from Product type
C. Defines a new Product type with fields upc and price
D. Creates a local copy of Product type without federation
Solution
Step 1: Understand 'extend type' in Apollo Federation
The extend type keyword adds fields to a type defined in another service.
Step 2: Analyze the example
The Product type is extended to add the price field, while upc is marked as external, meaning it comes from the original service.
Final Answer:
Adds the price field to an existing Product type from another service -> Option A
Quick Check:
extend type = add fields to existing type [OK]
Hint: extend type adds fields to existing types [OK]
Common Mistakes:
Thinking extend type creates a new type
Confusing @external with local fields
Assuming extend type removes fields
4. Identify the error in this federated schema snippet:
type Review @key(fields: "id") { id: ID! body: String author: User }
Assuming User is defined in another service, what is missing?
medium
A. The User type should be imported explicitly
B. The author field should be marked with @external
C. The author field should be marked with @provides or @requires
D. The Review type should use extend keyword
Solution
Step 1: Understand referencing external entities
In Apollo Federation, to reference an entity type like User from another service, the schema must explicitly extend that type with its @key directive: extend type User @key(fields: "id") { id: ID! }.
Step 2: Analyze the snippet
The Review type references User via author: User but lacks the required extend declaration for User, which is necessary for the gateway to know this service can resolve User.
Final Answer:
The User type should be imported explicitly -> Option A
Quick Check:
Reference entities -> extend type @key [OK]
Hint: Extend referenced entities with @key [OK]
Common Mistakes:
Marking author field with @provides or @requires
Marking author field as @external
Using extend keyword for Review type
5. You have two services: Accounts defining type User @key(fields: "id") { id: ID! name: String } and Reviews extending User with extend type User @key(fields: "id") { id: ID! reviews: [Review] }. How does Apollo Federation resolve the User entity across these services?
hard
A. It requires manual merging of User data in the gateway
B. It duplicates User types separately in each service
C. It ignores the extend type and uses only the Accounts User type
D. It merges User types by matching the @key field 'id' across services
Solution
Step 1: Understand @key usage in federation
The @key directive identifies the unique field used to match entities across services.
Step 2: Analyze entity resolution
Apollo Federation merges types with the same @key field by matching their unique identifiers, combining fields from both services.
Final Answer:
It merges User types by matching the @key field 'id' across services -> Option D