Bird
Raised Fist0
GraphQLquery~10 mins

Apollo Federation concepts in GraphQL - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

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
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a federated service with a key directive.

GraphQL
type Product @key(fields: "[1]") {
  id: ID!
  name: String
}
Drag options to blanks, or click blank then click option'
Aname
Bid
Csku
Dprice
Attempts:
3 left
💡 Hint
Common Mistakes
Using a non-unique field like 'name' as the key.
Omitting the @key directive entirely.
2fill in blank
medium

Complete the code to extend a type from another federated service.

GraphQL
extend type User @key(fields: "[1]") {
  id: ID! @external
  reviews: [Review]
}
Drag options to blanks, or click blank then click option'
Aid
Bprofile
Cusername
Demail
Attempts:
3 left
💡 Hint
Common Mistakes
Using a non-key field in the @key directive.
Not marking the key field as @external.
3fill in blank
hard

Fix the error in the code by completing the directive to specify the field used for reference resolution.

GraphQL
type Review @key(fields: "[1]") {
  id: ID!
  body: String
  author: User @provides(fields: "username")
}
Drag options to blanks, or click blank then click option'
AauthorId
Breviewer
CuserId
Did
Attempts:
3 left
💡 Hint
Common Mistakes
Using a non-existent or incorrect field name in @key.
Confusing @provides with @key directive usage.
4fill in blank
hard

Fill both blanks to correctly define a federated entity with a reference resolver.

GraphQL
extend type Product @key(fields: "[1]") {
  id: ID! @external
  price: Int
  weight: Int
}

const resolvers = {
  Product: {
    __resolveReference(product) {
      return [2];
    }
  }
};
Drag options to blanks, or click blank then click option'
Aid
Bproduct.id
Cproduct
Dprice
Attempts:
3 left
💡 Hint
Common Mistakes
Returning only a field like product.id instead of the full product.
Using a wrong field name in the @key directive.
5fill in blank
hard

Fill all three blanks to define a federated schema with a service and a query that fetches an entity by key.

GraphQL
type Query {
  productById(id: ID!): Product
}

type Product @key(fields: "[1]") {
  id: ID!
  name: String
  price: Int
}

const resolvers = {
  Query: {
    productById(_, args) {
      return [2];
    }
  },
  Product: {
    __resolveReference(reference) {
      return [3];
    }
  }
};
Drag options to blanks, or click blank then click option'
Aid
Bproducts.find(p => p.id === args.id)
Cproducts.find(p => p.id === reference.id)
Dname
Attempts:
3 left
💡 Hint
Common Mistakes
Using wrong field names in the @key directive or resolvers.
Returning incomplete objects in __resolveReference.

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

  1. Step 1: Understand Apollo Federation's role

    Apollo Federation is designed to combine multiple GraphQL services into one unified API.
  2. 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.
  3. Final Answer:

    To combine multiple GraphQL services into a single API -> Option C
  4. 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

  1. Step 1: Recall the directive for unique identifiers

    In Apollo Federation, the @key directive marks the unique identifier fields for an entity.
  2. 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.
  3. Final Answer:

    type User @key(fields: "id") { id: ID! name: String } -> Option B
  4. 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

  1. Step 1: Understand 'extend type' in Apollo Federation

    The extend type keyword adds fields to a type defined in another service.
  2. 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.
  3. Final Answer:

    Adds the price field to an existing Product type from another service -> Option A
  4. 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

  1. 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! }.
  2. 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.
  3. Final Answer:

    The User type should be imported explicitly -> Option A
  4. 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

  1. Step 1: Understand @key usage in federation

    The @key directive identifies the unique field used to match entities across services.
  2. Step 2: Analyze entity resolution

    Apollo Federation merges types with the same @key field by matching their unique identifiers, combining fields from both services.
  3. Final Answer:

    It merges User types by matching the @key field 'id' across services -> Option D
  4. Quick Check:

    @key fields unify entities across services [OK]
Hint: Entities merge by matching @key fields [OK]
Common Mistakes:
  • Thinking types are duplicated instead of merged
  • Assuming extend type is ignored
  • Believing manual merging is required