graphqlmicroservicesapollo-federation

Does using Apollo Federation with microservices actually make any sense?


We recently switched our tech stack from multiple, fully-encapsulated microservices to Apollo Federation. Each microservice was converted to a subgraph and the supergraph is federated by the gateway.

But lately it feels like we've lost some of the major pluses of working with microservices-- decoupled deployments, async inter-service communication, tons of extra wiring and time spent coordinating development to keep the supergraph stable across multiple environments.

It feels like we've regressed to a more monolithic style of working, but with independent teams and services.

Since Apollo hasn't been around for a while, and was developed against the GraphQL spec, which was initially intended to speed up Facebook's latency issues back when it was a monolith, I can't help but wonder if it's just not in a place yet to fully support microservice architectures. I sometimes wonder if it's overkill to do both Apollo Federation and microservices.

TL;DR:

Is using Apollo Federation with microservices just a bleeding-edge buzzy endeavor with diminishing returns on investment or does it make actual sense?

What are the (I imagine small number of) use cases in which doing this would make sense?

How do we retain benefits of working with pure microservices (namely, not coordinating small changes across tons of services in lockstep) in a Federation paradigm?


Solution

  • How do we retain benefits of working with pure microservices (namely, not coordinating small changes across tons of services in lockstep) in a Federation paradigm?

    I believe that Apollo Federation is mainly useful due to the principle of separation of concerns. With this, you do not need to coordinate small changes across tons of services in lockstep. For example, say you have a Reviews subgraph and a Users subgraph. As long as the two subgraphs know the key for the other entity, they can use it without needing to coordinate changes amongst themselves. If team A implements things related to only their concern, they should ideally never have to coordinate a change with another team.

    Is using Apollo Federation with microservices just a bleeding-edge buzzy endeavor with diminishing returns on investment or does it make actual sense?

    If you already have microservices which are completely independent of each other, using Apollo Federation may not be the ideal tool you might want to go with. There are other open source solutions out there that would help you combine your microservices under a single gateway (such as GraphQL-mesh, Stepzen, etc.) - and these do not require your microservices to support federation. That being said, there are teams out there that still stick with Apollo Federation because of its innate ability to help separate out subgraphs in a relatively clean way though the concept of ownership separation of concerns. So there are definitely use cases (i.e. when one subgraph has to use an entity owned by another subgraph) where using Apollo Federation has an impact.