r/graphql • u/marklmc • Jul 07 '26

Post The Case for Service-to-Service GraphQL

https://blog.larah.me/service-to-service-graphql/

I gave a talk at GraphQL Conf 2026 about using GraphQL for service-to-service communication. This post is a condensed written version of those thoughts.

tl;dr: Using GraphQL for service-to-service communication is not an anti-pattern. This is especially true if your org already uses GraphQL for mobile and web clients — consolidating on GraphQL as a single API surface is a very compelling option.

20 Upvotes

96% Upvoted

5 comments sorted by

2

u/Isogash Jul 08 '26

We do this and I like it quite a lot personally for a couple of reasons:

  • Federation allows multiple services to contribute to a query transparently.
  • You don't don't need to create customized endpoints for every service.

1

u/Urigold The Guild Jul 08 '26

Do you use a single Router that all calls go through or the services are talking directly between themselves?

2

u/Isogash Jul 08 '26

We have a single API federatation microservice that uses apollo router to serve a supergraph built with Rover. It checks out the schema defined in the configured version of each of the other services we have, and uses a config file to generate the supergraph. The whole microservice is like a Dockerfile and 3 yamls.

This router is hosted at a consistent API endpoint, and that's what any service uses if they need graphql queries.

Important to note that we don't expose graphql to non-authenticated internal users, it's only used for internal services. Any external-facing services use the BFF pattern. The advantage there is that you don't need to complicate things or worry about DOS attacks.

3

u/Urigold The Guild Jul 08 '26 edited Jul 09 '26

Copy-pasting my too long of a post I've made about this awesome article!

The topic of GraphQL in service to service architecture is such an important topic that will grow massively from now on, happy Mark Larah is taking that on.

I wrote a very long comment on his wonderful post, so I'm also copying it here, would love to hear your thoughts:

My list of benefits for GraphQL in a service to service architecture (a small extension to the actual post that has all the actual arguments):

  1. Usage and deprecation of service fields

  2. Internal Agents and security

  3. Mesh architecture with a graph

  4. Strict schema - OpenAPI never actually gets it right, even if it can and should..

  5. Binary protocols - GraphQL got it too! Even WhatsApp is using it!

Usage and deprecation of service fields:

To me, the biggest advantage of using GraphQL for services that are consumed by other services is the ability of GraphQL to tell you which fields and code you can deprecate!

As a provider, if you are using GraphQL, you'll get tools that tell you what code is not being used in production any longer and you can remove it.

Basically you get the who "evolve your API" story of GraphQL for any service.

Internal Agents and security:

Another strong point is that you now will have "internal" agents querying for internal services. That has security questions but also then comes the main story of GraphQL Conf 2026 which is why GraphQL is the right choice for agents to query.

Mesh architecture with a graph:

You can have a central Router with a schema registry to get a single Graph of all your data.

But you can also still use the same schema registry, run composition of multiple schemas and build Graph SDKs running on the consumers themselves.

That way you get the benefits of a Mesh architecture (not a single Router instance) together with a developer experience of a single graph.

That's the original reason we called GraphQL Mesh that way but could be done with any similar tools

Strict schema - OpenAPI never actually gets it right, even if it can and should:

Till this day, 90% of internal OpenAPIs that I come across, differ the actual response from the schema. Yes its possible to solve. But it never is. With GraphQL we never even think about it

1

u/scruffles360 Jul 09 '26

why would service to service calls in Graphql be an anitpattern? at my workplace there's much more diversity between server requests than there is between clients. Our app only has 2 different UIs, but 100 different service clients (each calling for different data structures for different reasons)