How do I combine multiple GraphQL services?

You have four main options, ranging from manual to declarative — here's the summary, given we've covered federation and stitching in detail earlier in this conversation:

1. Schema stitching

Server-side technique: introspect each GraphQL API's schema, then merge them into one unified schema that a gateway exposes at a single endpoint Simple to implement and gives clients a unified query interface, but it's manual — you own resolving naming conflicts, and one team typically has to own the stitched gateway itself Best suited to smaller systems or a handful of services, since manual conflict resolution and ownership don't scale cleanly to many teams

2. Apollo Federation

A specification (not just a technique) for designing one GraphQL API that's implemented across multiple independently-owned services from the start More declarative than stitching — each subgraph team just marks entities with @key and extends types they don't own, and the gateway composes everything automatically The main advantage over stitching: you're more likely to end up with a consistent API design, since each subgraph is designed with federation in mind rather than being retrofitted together after the fact The limitation: federation works great when all subgraphs are under your control, but it doesn't really solve merging in third-party APIs you don't own — for that you're back to stitching-style techniques or GraphQL Mesh

3. GraphQL Mesh / API aggregation

Turns almost any data source — REST (via OpenAPI), gRPC, databases, or existing GraphQL APIs — into a unified GraphQL schema, using per-source handlers you configure declaratively Notably not limited to combining GraphQL services with each other; it's the tool for when some of what you're combining isn't GraphQL at all You can reshape the unified schema afterward — adding fields that resolve by joining data across sources (e.g., a Book.author field resolved via a separate Authors gRPC service) using directives like @resolveTo

4. Hasura GraphQL Joins / remote schema relationships

If you're already on Hasura, it offers a no-code way to join a remote GraphQL schema to another remote schema (or to your database) by mapping a field in one to a type in the other — e.g., mapping an order ID in a "store" schema to the corresponding order in a "fulfillment" schema No code changes to either underlying API required — the join is defined purely as configuration

The two things that get harder regardless of which approach you pick

Naming conflicts — the more schemas you combine, the more likely you'll hit type/field name collisions, requiring manual renames (prefixing, suffixing, camelizing) Auth across ownership boundaries — when you own the underlying API, you inject a user context into resolvers directly. When you don't own it (e.g., stitching in Shopify's GraphQL API), you need to figure out how to inject different credentials per user/role into a remote resolver you don't control — this is consistently the hardest unsolved problem across all four approaches

Practical recommendation

Multiple teams, all services under your control, want long-term consistency → Apollo Federation Small number of services, one team owns the gateway, want something working quickly → schema stitching Mixing GraphQL with REST/gRPC/databases → GraphQL Mesh Already on Hasura and want a no-code join → Hasura GraphQL Joins