The Case for 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.

Specifically, here’s where I think it makes the most sense:

#Use Cases

Here are some good candidates in particular for using GraphQL on the backend:

Server Driven UI: This is a pattern employed at companies such as Netflix, Airbnb and Yelp to enable the server to make decisions about what UI widgets are displayed on the client. In many cases, the SDUI payload sent to the client contains the data already embedded into the component. Which means the SDUI backend service needs data from somewhere…

LLM Driven UI: A special case of the above — pages driven by LLMs (typically conversational UIs). The model needs product and user data in order to generate a response. This could be via MCP, or some prefetched data baked into initial context. Either way - we have a service that needs data!

React Server Components: This one feels like cheating, but still counts! There’s already native client support.

In all cases above, the data we provide may ultimately be displayed to end users. Therefore it needs to have the same business logic and auth checks applied as your existing external API - otherwise we risk leaking private information through the model and back out to the user. So from a safety perspective alone, it would be nice to directly reuse the external GraphQL API which already handles these concerns… on the server :)

#The case against service-to-Service GraphQL

If we’re evaluating the “best” data transport protocol purely for service-to-service use cases, binary protocols offer an excellent developer experience, and win on raw performance alone (e.g. gRPC, cap’n’proto, bebop to name a few). More commonly used however, are old-fashioned REST endpoints (ideally typed with Swagger/OpenAPI or similar).

A “boring” stack would reasonably be:

• REST or gRPC for service-to-service communication
• GraphQL for client-to-service communication (Yes, I think GraphQL counts as boring now!)

The natural next step is combining these: an external GraphQL API layered over a set of internal endpoints. This is indeed largely how GraphQL evolved and has been deployed at many companies.

More recently however, the industry has shifted towards GraphQL Federation as a way to deploy and orchestrate GraphQL across multiple services — replacing the need to wrap endpoints with a big GraphQL proxy service.

Which leads me to wonder: do we still need multiple APIs? Can we just reuse the GraphQL resolvers for internal service use cases too? Surely this is blasphemy!

#”No! GraphQL is for clients only. Keep separate APIs.”

In a situation where we maintain GraphQL resolvers and existing gRPC/REST endpoints, we have (at least) two APIs over the same sets of data. The trap we might fall into is this — duplicated data definitions over the same underlying data.

Clearly it would be a bad idea to duplicate API handler logic over the same data types each time. A separate business logic layer and/or using code generation tools such as ent or TypeSpec are well established patterns to keep things DRY and consistent. This certainly helps, but some logic cannot easily be normalized into a shared abstraction.

We still end up with:

• Per-API schema definitions (e.g. A GraphQL schema and an OpenAPI Contract)
• Different error handling patterns per API
• Different fields exposed for different use cases
• Features that don’t map cleanly to a shared abstraction (e.g. @skip/@include)

For instance, let’s take a closer look at error handling. The internal REST API might simply raise a 404:

@router.get("/business/{id}")
def get_business(
   id: int,
) -> BusinessResponse:
   business = lookup_business(id)

   if business is None:
       raise HTTPException(
           status_code=404,
           detail=f"Business {id} not found"
       )

    return BusinessResponse(**business)

Whereas our GraphQL resolver over the same data might instead return error unions:

@strawberry.type
class Query:
    @strawberry.field
    def business(self, info, id: strawberry.ID) -> Union[
        Business,
        BusinessNotFound,
    ]:
        business = lookup_business(id)

        if business is None:
            return BusinessNotFound(
                message=f"Business with id {id} not found"
            )

        return Business(**business)

This difference would be awkward to bake into the lookup_business(...) business logic layer. Per-API adaptor logic must be done per-API.

Let’s also zoom into the differences between the fields the external (GraphQL) and an internal (REST) service might return for the same domain object:

type Business {
  name: String!
  phoneNumber: String!
  isOpen: Boolean!
}

class BusinessResponse(pydantic.BaseModel):
    name: str
    phone_number: str
    opening_time: str
    closing_time: str

How many differences can you see?

The internal version exposes raw openingTime and closingTime values — but real users can only see a computed isOpen boolean field (which takes into account the user’s timezone).

But did you also spot the difference in phoneNumber? Trick question! It looks the same, but could actually be a totally different value — because for some businesses, we need to substitute a “call reporting number” instead when displaying to users via the external API. Values that look the same but are subtly different across different APIs becomes very confusing.

#GraphQL to the rescue

What if we consolidated on GraphQL, and let all client types, regardless of who or where they are in your application stack all fetch (mostly) the same data from the same API? 😱

type Business {
  id: ID!
  name: String!
  isOpen: Boolean!
  openingTime: String! @internalOnly
  closingTime: String! @internalOnly
  phoneNumber: String!
  phoneNumberRaw: String! @internalOnly
}

Just throw everything in GraphQL — both external and internal-only fields. There’s no penalty for doing so:

• Private fields can be kept private via an executable @internalOnly directive.
• Fields aren’t fetched unless requested in a query, so there’s no performance concern for including them all in the schema.

Better yet, use an @auth directive (or similar) to enforce granular RBAC or ABAC policies rather than a simple “public” vs “private” split.

(And better still, define and derive these policies from higher up in the stack, which is possibly the subject of different post 😅)

#Internal-only types

Some types will never be useful to be exposed via the external API. Services often need to expose some raw representation of data that must always be transformed into some other type before it’s useful to any client.

That’s fine! For example, consider the following two GraphQL services:

type Product {
  name: String!
  price: Float!
}

type Coupon @internalOnly {
  code: String
  percentage: Int
}

type User {
  eligibleOffers: [Coupon] @internalOnly
}

The Product.price resolver needs to call the offer_codes service in order to apply a modifier to the price displayed to the user.

This implies a GraphQL query executed from inside a GraphQL query. Weird, but fine. We’re ok with REST-inside-GraphQL, why not GraphQL-inside-GraphQL! Ideally the services/schemas could be restructured to avoid extra roundtrips, but this isn’t always possible, or worth the effort.

Prior art: “re-entrancy” is a first class feature of Viadict, Airbnb’s GraphQL monolith.

Taking things a step further, you could also use “Schema Contracts”, a common vendor feature to omit such internal-only types entirely from the external schema. (Apollo, WunderGraph, Hive)

#Summary

With the rise of more folks “vibecoding” and the demand for quicker product iteration in general, having a single, centralized, universally accessible source of your company data has never been more valuable.

There is a cost to maintaining multiple APIs types which only increases with the number of services, developers, API versions and client versions. GraphQL can serve all client types, and is uniquely positioned to serve both public and internal use cases particularly well.

GraphQL clients are widely already across many languages:

👉 https://graphql.org/community/tools-and-libraries/?tags=client

(If you don’t find a suitable client for your language, please comment!)

Maintaining one thing is easier than maintaining multiple things. In short:

Want to keep your backend DRY? Consolidate on a GraphQL API!

#Appendix