What are the benefits of Apollo Federation over a local modularization library like GraphQL Modules?

Question

When implementing a GraphQL solution it is often advantageous to modularize aspects of the graph to simplify the understanding, implementation, and testing of the complete graph. Apollo, a popular GraphQL solution vender, provides Apollo Federation as a solution to this problem, deprecating "stitching" solutions. Other solutions, such as GraphQL Modules, implement this sort of behavior on a local server level. GraphQL Modules even integrates with Apollo Federation, and they are not necessarily mutually exclusive.

It would be really helpful to have some guidelines that indicate why you would need to federate your GraphQL implementation over multiple servers. It adds a lot of complexity. At what point does Apollo Federation make sense over a local module solution like GraphQL Modules. Why would you consider utilizing both?

Answer 1

I tried to cover this topic (what GraphQL Federation is and when to use it) on my page.

In short, when you have a big monolithic GraphQL API, every team has to contribute their domain in one language and one tech stack (framework). The deployment queue may get longer and it will have an impact on productivity (speed of iteration). Also, when everyone contribute to the same codebase, to the same GraphQL server, then there's a chance that a change with a performance regression slips through, or something that causes a runtime exception that may kill your server.

GraphQL federation helps you solve those issues. When you break down your monolithic GraphQL API into smaller parts, called subgraphs, each team work on their domain independently and deploy at their own pace.

Thanks to the process called schema composition, the integrity of those subgraphs is validated and their schemas are combined into one unified schema, the supergraph, this way the distributed system feels like a monolithic API to the end GraphQL consumer.

Answer 2

These are really two unrelated concepts.

Schema modularalization is a pattern meant to keep your code organized and readable. It can be done using libraries like graphql-modules or merge-graphql-schemas, but it can also be implemented using the existing type extension syntax.

Apollo Federation is a distributed architecture akin to microservices architecture that allows you to implement multiple services that each expose an individual schema and are aggregated by a single gateway. We can view each individual service as a "module" of the schema exposed by the gateway -- but this modularization is incidental and is not the point of using federation. The point is the extra scalability you gain by implementing this sort of architecture.

So this really just comes down to why you would want to implement a microservices infrastructure in the first place. If you've got a large team working on a monolithic application, the scalability you gain may outweigh the added complexity and infrastructure costs. Otherwise, you should think very carefully about whether federation makes sense for your application.

Answer 3

Both of them also allow to divide a GraphQL schema into different smaller schemas and then combine them after that. But one of the main differences is that GraphQL Module only works in the single server while Apollo Federation can work across different servers.

So , suppose you divide a schema into 3 modules (User,Product and Review) as follows :

GraphQL Module only allows all modules are implemented at the same server . It provides a opinionated ways to guide you separate each modules configuration such as its schema and resolver into their own code packages only.

On the other hand , Apollo Federation allows these 3 modules to be implemented on separates servers/microservices and allow you to combine them as a single GraphQL server declaratively.