Federation vs Schema Stitching in GraphQL: Key Differences and Usage

In GraphQL, Federation is a modern approach that composes multiple services into a single graph with explicit ownership and declarative relationships, while Schema Stitching merges schemas by combining their types and resolvers manually. Federation offers better scalability and service autonomy, whereas schema stitching is simpler but less flexible for large distributed systems.

Quick Comparison

Here is a quick side-by-side comparison of Federation and Schema Stitching in GraphQL.

Factor	Federation	Schema Stitching
Architecture	Decentralized with service ownership	Centralized schema merging
Service Autonomy	High - each service owns its part	Low - merged schema managed centrally
Scalability	Designed for large distributed systems	Better for small to medium APIs
Type Merging	Uses @key and @extends directives	Manually merges types and resolvers
Complexity	More setup but clearer boundaries	Simpler but can get complex with many schemas
Tooling Support	Official Apollo Federation support	Community tools and manual setup

Key Differences

Federation is designed to let multiple GraphQL services work together by defining ownership of types and how they extend each other using special directives like @key and @extends. This means each service controls its own schema part, making it easier to scale and maintain large APIs.

In contrast, Schema Stitching combines multiple schemas into one by merging their types and resolvers manually or with helper libraries. It treats the combined schema as a single unit, which can become hard to manage as the number of services grows.

Federation enforces clear boundaries and communication between services, while schema stitching is more flexible but can lead to conflicts or duplicated types if not carefully managed. Federation also has official tooling support, making it the preferred choice for modern microservice GraphQL architectures.

Code Comparison

Here is an example of how Federation defines a user service with ownership and key directives.

javascript

const { buildFederatedSchema } = require('@apollo/federation');
const { ApolloServer, gql } = require('apollo-server');

const typeDefs = gql`
  type User @key(fields: "id") {
    id: ID!
    name: String
  }

  extend type Query {
    user(id: ID!): User
  }
`;

const resolvers = {
  User: {
    __resolveReference(user) {
      return { id: user.id, name: "Alice" };
    }
  },
  Query: {
    user(_, { id }) {
      return { id, name: "Alice" };
    }
  }
};

const server = new ApolloServer({ schema: buildFederatedSchema([{ typeDefs, resolvers }]) });

server.listen({ port: 4001 }).then(({ url }) => {
  console.log(`User service ready at ${url}`);
});

Output

User service ready at http://localhost:4001/

Schema Stitching Equivalent

Here is how you might stitch two schemas manually using @graphql-tools/stitch to combine user and product schemas.

javascript

const { stitchSchemas } = require('@graphql-tools/stitch');
const { makeExecutableSchema } = require('@graphql-tools/schema');
const { ApolloServer, gql } = require('apollo-server');

const userTypeDefs = gql`
  type User {
    id: ID!
    name: String
  }

  type Query {
    user(id: ID!): User
  }
`;

const productTypeDefs = gql`
  type Product {
    id: ID!
    name: String
    ownerId: ID
  }

  type Query {
    product(id: ID!): Product
  }
`;

const userResolvers = {
  Query: {
    user(_, { id }) {
      return { id, name: "Alice" };
    }
  }
};

const productResolvers = {
  Query: {
    product(_, { id }) {
      return { id, name: "Book", ownerId: "1" };
    }
  }
};

const schema = stitchSchemas({
  subschemas: [
    { schema: makeExecutableSchema({ typeDefs: userTypeDefs, resolvers: userResolvers }) },
    { schema: makeExecutableSchema({ typeDefs: productTypeDefs, resolvers: productResolvers }) }
  ],
  typeDefs: gql`
    extend type Product {
      owner: User
    }
  `,
  resolvers: {
    Product: {
      owner(product) {
        return { id: product.ownerId, name: "Alice" };
      }
    }
  }
});

const server = new ApolloServer({ schema });

server.listen({ port: 4002 }).then(({ url }) => {
  console.log(`Stitched schema server ready at ${url}`);
});

Output

Stitched schema server ready at http://localhost:4002/

When to Use Which

Choose Federation when building a large, distributed GraphQL API with multiple teams owning different services. It provides clear ownership, better scalability, and official tooling that simplifies managing complex graphs.

Choose Schema Stitching for smaller projects or when you need quick schema merging without the overhead of setting up federation. It works well if your API is less complex and you want to combine schemas manually.

Key Takeaways

Federation offers decentralized ownership and is ideal for large distributed GraphQL services.

Schema Stitching merges schemas centrally and suits smaller or simpler APIs.

Federation uses directives like @key and @extends for type relationships; stitching merges types manually.

Federation has official tooling support, making it easier to maintain at scale.

Choose Federation for scalability and team autonomy; choose stitching for simplicity and quick merges.