skip to content

What is Apollo Federation in GraphQL, and what problem does it solve?

level: juniorimportance: should knowfreq 45%

answer

  1. subgraph -> supergraph -> router
  2. one graph for clients, many owners
  3. type split across services via @key
  4. _service and _entities are the plumbing
  5. Spring = subgraph, not the router

basics

~10 s

Federation lets several small GraphQL services (subgraphs) be combined into one big schema (a supergraph). A router sits in front so clients query one endpoint, while each team owns and runs its own service.

solid answer

~40 s

Apollo Federation is an architecture for splitting one GraphQL API across multiple independently deployed services called subgraphs. Each subgraph (e.g. a Spring for GraphQL app) owns part of the schema, and a gateway/router composes them into a single supergraph that clients query at one URL. The router resolves a client query by planning which subgraphs to call and in what order, then merges the results. Types can be split across subgraphs: a Book type might be defined in a catalog subgraph and extended in a reviews subgraph. This solves the monolith-vs-microservices tension for GraphQL: you keep one unified graph for clients while letting teams develop, own, and deploy their slice independently. Spring for GraphQL supports acting as a subgraph via its federation module.

code

graphql · 11 lines
graphql
# catalog subgraph owns Book
type Book @key(fields: "id") {
  id: ID!
  title: String!
}

# reviews subgraph EXTENDS the same Book
type Book @key(fields: "id") {
  id: ID!
  reviews: [Review!]!   # added by a different service
}

go deeper

for a junior

Know the words subgraph, supergraph, router and the one-line problem statement (unify many services under one graph).

for a middle

Explain that types can be split/extended across subgraphs and that a key identifies entities.

for a senior

Contrast federation with schema stitching and explain composition happening at build time.

for a principal

Weigh federation vs a modular monolith; discuss ownership, versioning, and operational cost of running a router.

## The problem A single large GraphQL schema in one service becomes a bottleneck: every team edits the same codebase and deploys together. But you also don't want clients juggling many GraphQL endpoints and manually joining data. **Apollo Federation** resolves this: one unified graph for clients, many independently owned services behind it. ## Key terms - **Subgraph** — a single GraphQL service owning part of the overall schema. A Spring for GraphQL app is a subgraph. - **Supergraph** — the composed schema formed by stitching all subgraphs together. It is built at deploy time (composition) from each subgraph's SDL. - **Router / Gateway** — the front door (Apollo Router, or the older `@apollo/gateway`). Clients send queries here. It holds the supergraph schema, builds a **query plan**, calls the needed subgraphs, and merges responses. - **SDL** — Schema Definition Language, the text form of a GraphQL schema. ## How a type spans subgraphs Federation's power is that one entity type can be owned by one subgraph and referenced/extended by others. A `catalog` subgraph defines `Book`; a `reviews` subgraph adds a `reviews: [Review]` field to that same `Book`. The router knows how to fetch the base `Book` from catalog and the reviews from reviews and glue them by a shared key. This is enabled by federation **directives** in the schema — chiefly `@key`, which names the field(s) that uniquely identify an entity so the router can pass a reference between subgraphs. ## Two special fields every subgraph exposes Federation requires each subgraph to expose two things the router uses under the hood (you do NOT normally call them yourself): - `_service { sdl }` — returns the subgraph's own schema as text, so the composition tool can read it. - `_entities(representations: [_Any!]!): [_Entity]!` — lets the router hand a subgraph a list of entity references ("here is a Book with id 42") and get back the fully resolved objects. This is how one subgraph resolves entities that were introduced by another. ## Where Spring fits Spring for GraphQL can act as a **subgraph** (not the router). You add its federation support, mark controller methods with `@EntityMapping` to answer `_entities` lookups, and Spring generates the `_service`/`_entities` machinery for you. Spring does not implement the router — you run Apollo Router (or gateway) separately. ## When to use Use federation when multiple teams need to contribute to one graph, or when your GraphQL layer has grown too big for a single deploy. For a small single-team API it is overhead you don't need — a plain single Spring for GraphQL schema is simpler. ## Gotcha Federation is a runtime + build-time contract, not just a library. Even after wiring the Spring side, you still need a composition step (Apollo `rover supergraph compose` or Apollo GraphOS) and a running router. The Spring app alone is only one piece.

  • Does Spring for GraphQL implement the router/gateway?
    No. Spring implements the subgraph side (schema + entity resolution). You run Apollo Router or the Apollo gateway separately to compose subgraphs and route client queries.

context

resolving links…