In advance of its GraphQL Summit this week, GraphQL tooling provider Apollo has released a series of updates to its Apollo Federation tooling, which it first launched in 2019 and has since become an accepted pattern for breaking down monolithic architectures through application programming interfaces (APIs).
This week’s launch includes the integration of federation into Apollo Studio, an updated Apollo Workbench Visual Studio Code extension, and the introduction of the Rover command-line interface (CLI) to more easily bring GraphQL design and testing into the enterprise continuous integration and continuous delivery (CI/CD) pipeline.
The GraphQL query language upends the traditional REST API pattern by offering the ability to request a fine grained response rather than a firehose of information. But enterprises turning to GraphQL found themselves facing a similar conundrum over time: their GraphQL deployments were becoming unmanageable monoliths. Netflix recently offered its own telling of this story, relating how their graph had become so large that it was unknowable by any one member of its API team. In response, the company’s engineers broke down their graph into pieces using GraphQL Federation, wherein individual teams owned their own piece of the graph, which was then presented by a single, unified API gateway.
Apollo Chief Technology Officer and co-founder Matt DeBergalis compares GraphQL Federation to a number of other modern technologies in its ability to break down a monolithic architecture into composable pieces, enabling agility at the team level.
“Federation is an answer to how you can do that organically, how each team can take on its own piece of the puzzle to solve their own needs, but in a way that composes together into a structured whole, similar to how React lets multiple teams build pieces of a UI that coexist gracefully on the screen together, or similar to how Kubernetes allows multiple teams to each run their own microservice in a common environment without stepping on each other’s toes,” explained DeBergalis.
“I think the story of the last few years in the enterprise is composability. A federated graph is the first composable API. It lets multiple teams each focus on their piece of the puzzle, but in a way that allows them to leverage each other’s work and leads to something that’s greater than the sum of its parts.”
Starting with the integration of federation into Apollo Studio, this week’s releases are designed to help enterprises adopt federation and to “chart an incremental path from the APIs they have to a common data graph,” explained DeBergalis. Apollo Studio does this by helping teams understand who owns what part of the graph and facilitating communication between them. Apollo Studio will also help visualize how queries that pull data from different parts of the graph will function, especially in response to changes to the graph.
Similarly, Apollo Workbench brings that same sort of functionality directly into VS Code, allowing developers to model graphs as well as validate how it composes in relation to what other teams have done. Again, the idea of a federation is to break down the API ownership into smaller, composable bits, and these tools are meant to facilitate that.
“The model we recommend is almost a controlled chaos approach to this. You don’t want a waterfall approach, you want an approach where each team can move quickly, and what that leads to is a really healthy convergence over time,” said DeBergalis. “One of the things we hear from virtually every customer we work with is how important it is to educate teams on best practices around graph design, and how to practice a central graph capability in the company that reflects that, and so the tools are designed to do exactly that.”
Finally, the Rover CLI brings the testing, publishing, and management of schema changes to the CI/CD pipeline with a single, lightweight binary built in Rust. While having GraphQL be part of the CI/CD pipeline may not be new, DeBergalis explained that the significance of Rover is its ability to function in the numerous environments often present in enterprises, which often have a mix of legacy and modern infrastructure. Overall, explained DeBergalis, it is this agility that defines federation on the whole, bringing GraphQL the ability to function in disparate environments, rather than forcing large, heterogeneous enterprises to stuff everything into a single, homogeneous monolith.
“You’re never going to roll out a monolithic GraphQL server to handle the needs of a complete enterprise. That is absolute nonsense. What you need is a declarative approach, a modular approach,” said DeBergalis. “That’s what federation is, where each piece of that graph is implemented separately in its own language, its own DevOps infrastructure, all of that stuff decoupled, and then federation is the glue.”