SYSTEM Cited by 2 sources

Apollo Federation¶

Definition¶

Apollo Federation is Apollo's architecture for composing a single unified GraphQL schema (supergraph) from many independently-owned GraphQL services (subgraphs). Each subgraph declares the types and fields it owns; a federation router composes them into the supergraph schema and executes cross-subgraph queries by dispatching per-field resolution to the owning subgraph.

Why organisations adopt it¶

Team-scoped ownership. Each subgraph can be owned, deployed, and evolved by one team without coordinating schema PRs with every other team.
One API for all clients. Clients see a single GraphQL endpoint and one schema; they don't need to know which subgraph backs which field.
Incremental migration. New domains can be added as subgraphs without touching existing services.

Canonical wiki instance (Yelp CHAOS)¶

Yelp operates an Apollo Federation supergraph with a per-domain subgraph per major product area. The CHAOS server-driven-UI framework lives as its own dedicated subgraph in this supergraph, written in Python using Strawberry. The CHAOS subgraph authenticates requests, routes them to the appropriate CHAOS backend service (which implements the CHAOS REST API), and formats the response back into the supergraph-visible chaosConfiguration shape.

Verbatim from the 2025-07-08 post: "At Yelp, we have adopted Apollo Federation for our GraphQL architecture, utilizing Strawberry for federated Python subgraphs to leverage type-safe schema definitions and Python's type hints. The CHAOS-specific GraphQL schema resides in its own CHAOS Subgraph, hosted by a Python service."

This is the wiki's canonical instance of patterns/federated-graphql-subgraph-per-domain.

Comparison with alternatives¶

Schema stitching (Apollo's earlier approach): gateway pulls multiple schemas and tries to merge them at runtime; error-prone, hard to scale with team count.
Monolithic GraphQL: one server owns the entire schema; becomes a release-coordination bottleneck.
Netflix DGS + Enterprise GraphQL Gateway: Netflix's pre-Federation architecture — see systems/netflix-enterprise-graphql-gateway. Same shape, different implementation.
Federation v2 (current): improved composition rules and directives over Federation v1; supports shared types across subgraphs more ergonomically.

Seen in¶

sources/2025-07-08-yelp-exploring-chaos-building-a-backend-for-server-driven-ui — Yelp's CHAOS subgraph within the Yelp Federation supergraph; first wiki instance.
sources/2021-03-03-zalando-how-we-use-graphql-at-europes-largest-fashion-e-commerce-company — Zalando's UBFF names Apollo Federation as the explicit not-chosen alternative. Quote: "instead of having multiple Graphs connected via a library and gateway we have a single service at Zalando which connects all the domains in a single schema Graph. This has tradeoffs which we have addressed as mentioned here, since we gain by keeping a single Graph in terms of tooling, deployment and governance." First on-wiki articulation of when not to federate.

systems/strawberry-graphql — Python library Yelp uses to implement their federated subgraph
systems/zalando-graphql-ubff — the explicit not-federated alternative: single service, single schema, no runtime composition
systems/netflix-enterprise-graphql-gateway — comparable non-Apollo approach
patterns/federated-graphql-subgraph-per-domain
patterns/unified-graphql-backend-for-frontend — the counter-pattern
patterns/graphql-unified-api-platform — the older pattern this is a specific implementation of