0

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?

sharknado
  • 25
  • 12

1 Answers1

2

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.

DharmanBot
  • 1,066
  • 2
  • 6
  • 10
the stack goat
  • 66
  • 5
  • Entities changing aren't really an issue, the issue is when you change value types. Apollo docs specifically state that value types that are shared are to be duplicated across subgraphs, but if one needs to change in one subgraph, every service that shares that duplicated type with the same name has to make the change at the same time and for each environment. Value types are more ubiquitous than entities, so this poses a real problem when trying to set up a unified API with shared scalars or value types. – sharknado Apr 05 '22 at 19:31
  • But yes, I appreciate you listing other solutions that solve the problem we were trying to solve initially in a way that does not introduce these perils. Will take a look! Thank you! – sharknado Apr 05 '22 at 19:32
  • 1
    > Entities changing aren't really an issue, the issue is when you change value types. You're right -maintaining backward compatibility is an issue, but here is how i solve it: 0) Plan ahead so that this doesn't happen 1) if it does happen, create a second variable with a similar name - and mention in the doc that the former variable is deprecated. 2) inform other subgraph teams about the change. this would give ppl time to make the change If you use pure microservices, you would have to do something similar anyway. Unfortunately, you can't change a type that someone else ... – the stack goat Apr 11 '22 at 06:39
  • 1
    ... is using without letting them know + giving them time to change it :( (sorry had to split this answer into 2 parts since Stack overflow said it was too long, but i hope this helps!) If not - let me know and i can try my best to help a bit more :) (also - incase this helped, please consider upvoting) – the stack goat Apr 11 '22 at 06:41