Skip to content

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.
  • Airbnb Viaduct (added 2026-05-15): Airbnb's GraphQL multi-tenant runtime that hosts many tenant modules per runtime. Viaduct is positioned by its authors as complementary, not alternative: a Viaduct instance can participate as a subgraph inside a federated supergraph, so a "large organization where hundreds of teams contribute to the overall graph" can run "a smaller number of Viaduct instances, each hosting many closely related tenant modules" and let Federation compose them. Compared with N × M independent subgraph servers, this collapses per-team operational cost by a factor of M while preserving Federation's cross- organization composition. The framing quote: "Federation distributes development by distributing servers. Viaduct distributes development by distributing modules." Source: sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh.

Seen in

  • sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh — Airbnb's Viaduct 1.0 announcement names Federation as the complementary composition layer above multi-tenant Viaduct runtimes, not as a competing alternative. First on-wiki articulation of "Federation as the cross-runtime composition layer for multi-tenant GraphQL runtimes."
  • 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.
  • — 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.
Last updated · 542 distilled / 1,571 read