Introduction to Apollo Federation

In this tutorial, you will learn about Introduction to Apollo Federation. We cover key concepts, practical examples, and best practices to help you master this topic.

Apollo Federation enables splitting a Graphql schema across multiple services (subgraphs) that compose into a single unified graph. Each subgraph owns part of the schema, and a gateway combines them seamlessly.

What You'll Learn

• Federation architecture and when to use it
• Defining entities with the @key directive
• Federated resolvers and reference resolution
• Gateway configuration and supergraph composition
• Subgraph boundaries and ownership

Why It Matters

As GraphQL schemas grow, single-server architectures become bottlenecks. Federation lets teams own independent subgraphs aligned with microservice boundaries. The gateway presents a unified API to clients.

Real-World Use

Netflix uses federated GraphQL for their studio API. Apollo's own managed federation powers enterprise graphs. Many organizations adopt federation when their schema exceeds 50 types across multiple teams.

flowchart TD
    Client[Client App] --> Gateway[Apollo Gateway]
    Gateway --> SubgraphA[Subgraph: Users]
    Gateway --> SubgraphB[Subgraph: Products]
    Gateway --> SubgraphC[Subgraph: Orders]
    SubgraphA --> DB1[(Users DB)]
    SubgraphB --> DB2[(Products DB)]
    SubgraphC --> DB3[(Orders DB)]
    Gateway --> Supergraph[Composed Supergraph Schema]

Teacher Mindset

Each subgraph should be owned by a single team and aligned with a bounded context. The @key directive tells the gateway how to identify entities across subgraphs. Reference resolvers let subgraphs contribute fields to entities they do not own.

Code Examples

# Example 1: Users subgraph with entity
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

type Query {
  user(id: ID!): User
  users: [User!]!
}

# Example 2: Reviews subgraph extending User
type Review @key(fields: "id") {
  id: ID!
  body: String!
  rating: Int!
  author: User!
}

extend type User @key(fields: "id") {
  id: ID! @external
  reviews: [Review!]!
}

type Query {
  review(id: ID!): Review
}

// Example 3: Entity reference resolver
const resolvers = {
  User: {
    __resolveReference: (ref) => {
      return db.users.findById(ref.id);
    }
  },
  Review: {
    author: (review) => {
      return { __typename: 'User', id: review.authorId };
    }
  }
};

Common Mistakes

• Making subgraphs too granular, causing excessive cross-subgraph queries
• Forgetting to add @external to fields extended from other subgraphs
• Creating circular dependencies between subgraphs
• Not handling entity reference resolution correctly
• Ignoring federated tracing and error propagation

Practice

1. Create a Users subgraph with the User entity.
2. Create a Products subgraph with the Product entity.
3. Extend User in a Reviews subgraph to add user reviews.
4. Set up an Apollo Gateway that composes both subgraphs.
5. Challenge: Add a third subgraph for Orders that references both User and Product.

FAQ

Mini Project

Split your library schema into two subgraphs: one for Authors and one for Books. The Books subgraph extends Author to list their books. Set up an Apollo Gateway that composes both subgraphs.

What's Next

Next, you will learn about GraphQL Security including depth limiting and query cost analysis.