Most engineering organisations decomposed their backends into microservices years ago. The client-facing API rarely kept pace: frontends still orchestrate calls across a dozen services, or lean on a gateway that has quietly become a monolith of its own. GraphQL has become a popular answer: a single, strongly typed schema through which clients request exactly the data they need, regardless of which service provides it.

That model carries a quiet assumption, however: one schema, and in practice one team that owns it.

Federated GraphQL removes the assumption. This session introduces federation from the ground up: dividing a graph into subgraphs aligned to existing service and team boundaries, then composing them into a supergraph that clients continue to see as one coherent schema. We will cover the mechanics in plain terms: entities and the @key directive, reference resolvers, how a router plans a single query across several services, and what composition validates at build time versus what still fails at runtime. We will also look at where the ecosystem is heading as the Composite Schemas working group standardises composition beyond any single vendor.

No production GraphQL experience is assumed: familiarity with APIs and microservices is enough.