GraphQL offers the enticing promise of enabling developers to design and evolve an API in a product-focused way while allowing clients to query data from a single endpoint and from any number backing data sources. But as GraphQL adoption gains traction across teams, a company may soon find itself in a scenario where it has an unwieldy monolithic API that has become a bottleneck to developer velocity. Alternatively, there may be multiple GraphQL APIs that emerged in tandem with some amount of overlap between them but no full representation of the company's queryable data.
Ultimately, the true value of the data graph (and the key to unlocking the breadth of capabilities it can enable) is based on its network effects. In this talk, I'll explore how Apollo Federation makes this possible by empowering teams to manage portions of the overall data graph across a distributed architecture. We'll also see how Apollo Federation's declarative, incremental approach to GraphQL consolidation allows teams to draw service boundaries based on an intuitive separation of concerns and without the trade-offs of a monolithic GraphQL API.