Schema Composition — Federation Basics

What you'll walk away with

Explain the core ideas behind Schema Composition — Federation Basics
Run the sample GraphQL query or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

A single monolithic GraphQL server tends to create deployment and ownership conflicts as a team grows — each team wants to own and deploy its own domain within the schema. Apollo Federation's core idea is that each team's subgraph schema identifies shared entities (like `Tutorial`) with an `@key` directive, and a gateway (router) composes the subgraphs into one unified schema presented to clients.

Connect it to a real scenario

Suppose the Tutorial Platform splits into a `tutorials-service` (owns the Tutorial entity) and an `authors-service` (owns the Author entity): `tutorials-service` declares `Tutorial @key(fields: "id")`, and `authors-service` declares `Author @key(fields: "id")` while extending the `Tutorial.author` field. A client still queries one gateway and never needs to know the backend is split into services.

Monolithic schemas create ownership conflicts as teams grow
@key directives identify entities across subgraphs
A gateway composes subgraphs into one unified schema

Try the working example

graphql

# tutorials-service subgraph
type Tutorial @key(fields: "id") {
  id: ID!
  title: String!
  authorId: ID!
}

# authors-service subgraph
type Author @key(fields: "id") {
  id: ID!
  name: String!
}

extend type Tutorial @key(fields: "id") {
  id: ID! @external
  author: Author
}

You should see

You can explain federation's subgraph/gateway model and the role of the `@key` directive.

5-minute try-it

Design a `comments-service` subgraph and describe how its `Comment` entity would connect to `Tutorial` (owned by `tutorials-service`).

One important caution

Introducing federation too early, while a project still has one team and one service, adds operational complexity (gateway, subgraph deploy coordination) that outweighs the benefit — split only once the monolith and team have grown enough to need it.

Apollo Federation — Introduction — GraphQL

Easy traps

Introducing federation too early, while a project still has one team and one service, adds operational complexity (gateway, subgraph deploy coordination) that outweighs the benefit — split only once the monolith and team have grown enough to need it.
Validate sample queries and mutations on a local or test server with recoverable data before applying them to production.

Exercise

Design a `comments-service` subgraph and describe how its `Comment` entity would connect to `Tutorial` (owned by `tutorials-service`).

You'll know it worked when: You can explain federation's subgraph/gateway model and the role of the `@key` directive.