There are a few common ways to “stitch” GraphQL schemas together, depending on what you mean by stitching:

1) Schema stitching at the gateway level

You combine multiple GraphQL services into one unified schema, and the gateway delegates subqueries to the right downstream service.

Typical use case

• Service A owns User
• Service B owns Order
• You want clients to query both through one endpoint

Common tools

• GraphQL Tools (@graphql-tools/stitch)
• Older Apollo schema stitching approaches
• Often replaced today by Apollo Federation in new architectures

Example conceptually

You define a gateway schema that merges:

• Query.user
• Query.order
• type extensions like User.orders

The gateway resolves User.orders by calling the Orders service with the user ID.

---

2) Apollo Federation

This is the more modern approach for composing schemas from multiple services.

How it works

Each service exposes its own schema and marks key fields with federation directives like:

• @key
• @external
• @requires
• @provides

A federated gateway composes them into one supergraph.

Example

type User @key(fields: "id") {
  id: ID!
  name: String!
}

In another service:

extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

This is usually preferred over manual stitching for larger systems.

---

3) Manual schema merging

If you just want to combine SDL strings in one server, you can merge schemas programmatically.

Example with GraphQL Tools

import { mergeTypeDefs } from '@graphql-tools/merge';

const typeDefs = mergeTypeDefs([userTypeDefs, orderTypeDefs]);

Then you still need to merge resolvers:

import { mergeResolvers } from '@graphql-tools/merge';

const resolvers = mergeResolvers([userResolvers, orderResolvers]);

This is fine if you’re building a monolith or modular schema in one process.

---

4) Remote schema delegation

If you already have separate GraphQL endpoints, you can delegate queries from one schema to another.

Useful when

• One schema is a facade over others
• You want to enrich data from another GraphQL service

Tools

• graphql-tools delegation APIs
• executor functions
• stitching links / remote executors

---

Basic stitching pattern

If you’re using @graphql-tools/stitch, the idea is:

1. Create executable schemas for each service
2. Define subschema configs
3. Stitch them together
4. Add type merging / delegation rules for shared types

Simplified example

import { stitchSchemas } from '@graphql-tools/stitch';

const gatewaySchema = stitchSchemas({
  subschemas: [
    { schema: userSchema },
    { schema: orderSchema }
  ]
});

If both schemas define User, you’ll usually need type merging configuration so the gateway knows they refer to the same entity.

---

Important considerations

Shared types

If multiple services define the same type, you need a strategy:

• choose one as the canonical owner
• merge fields across services
• use entity keys like id

Nullability conflicts

If one schema says name: String! and another says name: String, you need to reconcile them carefully.

Performance

Stitching can cause:

• extra network round trips
• N+1 problems

Use batching/caching where possible.

Error handling

One downstream schema failing should not necessarily break the whole query unless that field is required.

---

What should you use?

• Single server / modular codebase: mergeTypeDefs + mergeResolvers
• Multiple GraphQL services: usually Apollo Federation
• Need custom gateway behavior over existing GraphQL services: schema stitching / delegation

---

If you want, I can show you:

1. a simple working example of schema stitching in Node.js, or
2. how to do it with Apollo Federation, depending on your setup.