Hi James! I’m a relatively new Solutions Architect at Apollo and I have some experience with GraphQL/gRPC/federation from my time at Square. Here’s my current take on the subject (which is still evolving and not an official Apollo position!)
gRPC is solid tech and I see no reason why you’d need to entirely abandon it. It’s especially great for efficiently and synchronously shipping bytes between services in the same domain (or bounded context, in DDD terms).
Once you leave that single domain and start supporting multiple end-user apps (that require data from multiple domains), gRPC becomes difficult to optimize and difficult to evolve.
- The RPCs are all-or-nothing (unless you invent your own query DSL in protobuf) and,
- You can’t compose multiple RPCs together (so clients have to manage a sequence of calls to multiple services to fetch everything they need.)
The ideal architecture, to me, is that a team/org within your company owns several microservices for different aspects of their domain and uses gRPC to communicate between them. They also own an GraphQL service that exposes the “public API” (not public to the world, just public to the rest of the company) as a GraphQL schema. The schema acts as an abstraction layer over your domain’s microservices, making it easier to refactor and optimize your underlying services while not changing the API that other teams and end-user apps rely on.
The notion that the GraphQL schema is an abstraction layer makes tools like GraphQL Mesh less attractive to me. It’s great if you just want to get things started quickly (like Airbnb did) and have your GraphQL schema map directly to your RPC interfaces. But:
- Your GraphQL schema will have to change at the same rate as your RPC interfaces, making it harder to carefully evolve either.
- Sticking to GraphQL schema design best practices and idioms will be harder.
- You’ll need extra configuration or logic to take advantage of GraphQL’s compositionality.
IMHO, there’s no silver bullet for making a GraphQL interface on top of another API. The tools that purport to allow this will restrict you from making the best API possible today, and from being able to gradually evolve it in the future.
I recommend looking at graphql-kotlin or DGS for hand-writing GraphQL services for your domains. They can be thin, efficient, and relatively easy to write and test, and also set you up for success in the future as your microservice landscape changes over time.
And of course, I doubly-recommend using Apollo Federation to compose all your GraphQL services into a single GraphQL API for end-user apps.
Hope this helps! Looking forward to your feedback as I continue to hone this argument.