You usually combine multiple GraphQL services in one of these ways:

1) GraphQL Federation

Best when you want multiple teams/services to own different parts of the schema, but expose one unified GraphQL API.

• Each service exposes its own schema
• A gateway composes them into a single graph
• Clients query one endpoint
• Common tools: Apollo Federation, GraphQL Mesh, Hasura Remote Schemas, Mercurius Federation

Good for:

• Large systems
• Microservices
• Independent deployment and ownership

Example idea:

• users service owns User
• orders service owns Order
• Gateway lets clients ask for user { orders { ... } }

---

2) Schema Stitching

You merge multiple GraphQL schemas into one “stitched” schema.

• Often used when you already have multiple GraphQL APIs
• A gateway delegates parts of the query to the right service
• Can be simpler for smaller setups, but less ergonomic than federation for large systems

Good for:

• Wrapping existing GraphQL APIs
• Transitional architectures

---

3) API Gateway / BFF Layer

Build a custom GraphQL server that calls multiple backends.

• Your GraphQL server acts as an orchestrator
• It queries REST, GraphQL, databases, or gRPC services
• You resolve fields manually in resolvers

Good for:

• Maximum control
• Mixed backend types
• Custom aggregation logic

Tradeoff:

• More code and maintenance

---

4) GraphQL Mesh

A tool that can unify many APIs, including GraphQL, REST, gRPC, and databases, into one GraphQL endpoint.

Good for:

• Rapid integration
• Heterogeneous systems
• Lower-code approach

---

Which should you use?

• Multiple GraphQL services owned by different teams: use Federation
• Existing GraphQL APIs you want to merge: use Schema Stitching or Mesh
• Need custom orchestration or non-GraphQL backends too: use a custom GraphQL gateway/BFF

---

Practical recommendation

If you are starting fresh with multiple GraphQL services, Apollo Federation is usually the most common choice.

High-level steps:

1. Define a base schema for each service
2. Mark shared entities with federation directives like @key
3. Expose each service separately
4. Put a gateway/router in front
5. Let the gateway compose the supergraph

---

If you want, I can also show:

• a simple Apollo Federation example
• a schema stitching example
• or help you choose based on your exact architecture.