Simply put, federated graphs are the implementations of Apollo’s “One Graph” principle for modern-day application development stack. ie., we can have a single unified data graph operating at the product’s data layer. With that, it will be easier for a client to query a single graph and get all the data without having to query different graphs for different data portions.
However, this would be challenging if the entire schema should consist of the codebase of the entire team’s data graph logic. Instead, even though there is just one schema on the forefront, the graphs are “federated” across teams and each time has the right to code/maintain the individual schema according to their release cycles.
Taking an example of a Tweet/Post and a User service in an application - the main task is to split this monolithic application into two parts - Tweet Service and User Service.
A normal person, who is not aware of Federated graphs would have the schema as follows -
How would a back-end dev resolve “tweets” in User? Write a join - to fetch tweets belonging to the user.
Now let’s say - you don’t have access to the tweets database?
A Federation fixes all this - there should be a complete separation of concern when working in a product. You shouldn’t be writing join queries to fetch the required data, instead be asking the “Tweet” team to give you the data. And the federated schema looks like:
Schema 1 - User – belongs to the User microservice. (let’s say its running on port 3001)
Schema 2 - Tweet - belongs to the Tweet microservice. (this one’s on port 3002)
We now have the federated gateway (on port 3000) - that combines the sub-graphs (using the term sub-graphs henceforth) - and presents to you a single unified schema.
You can take a look at this demo implementation - to understand how things work - https://codesandbox.io/s/managed-federation-demo-3c9z4. Head over to the playground of the Gateway to visit the combined schema.
Okay, so now that you know what a federated graph is - let’s bring back Apollo Federation - and its powerful “Managed Federation”.
Apollo will keep track of your sub-graphs
That’s it for now. Hope you got started on this. The Apollo docs have tons of info to get yourself into the world of Graphs. Or get in touch with KeyValue to experience the systematic approach we adopt using these supergraphs to glue our work together, and enable seamless data collaboration and scaleups.
The data in this article is referenced from multiple sources. You could do your reading on any of the sources to progress more into the details on a Federated Schema and the powerful features of a Managed Federation.
Apollo Federation is a framework for building federated GraphQL architectures. It allows multiple independently developed GraphQL services, called subgraphs, to combine into a single supergraph. This lets teams maintain their own schemas while exposing a unified data graph for clients to query seamlessly.
A federated GraphQL is an architecture where multiple independent GraphQL services, called subgraphs, work together as one unified supergraph. Each team manages its own schema and service, while a central gateway combines them to let clients query data from all sources through a single GraphQL endpoint.
Managed Federation, a feature of Apollo Federation, centralizes the management of subgraphs through Apollo Studio. It automatically tracks schema changes, validates compositions, and updates the supergraph without downtime. This ensures safe, version-controlled federation and seamless coordination across distributed GraphQL services.
Federated graphs enable seamless data collaboration by unifying multiple GraphQL services into one shared data graph. Each team can independently manage its own schema and service while contributing to a common supergraph, allowing cross-team data access and collaboration without disrupting individual workflows.
Yes. Each team can independently manage and deploy its subgraph, while Apollo Federation handles composition, ensuring consistent integration at scale.
