Schema Stitchingの基礎

Imagine having multiple GraphQL services, perhaps from different teams or even different backend technologies. How do you present them as a single, cohesive API to your frontend? That's where Schema Stitching comes in!

It allows you to combine multiple independent GraphQL schemas into one unified gateway schema.

In large applications, a single, massive API (a "monolith") can become hard to manage. Different teams might step on each other's toes, and deployments become risky.

• Slow Development: Changes impact the entire system.
• Deployment Risks: A bug in one part can bring down everything.
• Scaling Issues: Hard to scale specific parts independently.

Microservices break down an application into smaller, independent services. Each service can have its own data and API.

When each microservice exposes its own GraphQL schema, clients would need to know about and query multiple endpoints. This adds complexity for the frontend.

You might hear about GraphQL Federation too. While both unify APIs, they do it differently.

• Stitching: Combines existing schemas, often ideal for integrating legacy or third-party APIs.
• Federation: Designed for building new microservices from scratch, where each service contributes parts of a single, unified graph.

This lesson focuses on Stitching.

Think of a "stitching gateway" or "API Gateway". This gateway acts as a single entry point for clients.

It fetches schemas from individual backend services (called "sub-schemas") and then combines them into one "unified schema" that clients interact with. The gateway then delegates queries to the correct sub-schema.

Let's say we have two services:

• User Service: Manages user profiles.
• Product Service: Manages product listings.

Each exposes its own GraphQL schema:

# User Service Schema
type Query {
  user(id: ID!): User
}
type User {
  id: ID!
  name: String
  email: String
}

# Product Service Schema
type Query {
  product(id: ID!): Product
}
type Product {
  id: ID!
  name: String
  price: Float
}

The stitching gateway merges the root Query and Mutation types from all sub-schemas into a single root Query and Mutation type for the unified schema.

So, a client can query user(id: "1") AND product(id: "101") from the same endpoint.

What if a User needs to know about their Product orders? Stitching allows you to extend types. For example, the Product Service could extend the User type to add an orders field.

The gateway handles resolving this, by first querying the User Service for the user, then using that user's ID to query the Product Service for their orders.

Schema stitching offers several advantages:

• Unified API: One endpoint for all your services.
• Modularity: Teams can build and deploy services independently.
• Flexibility: Easily integrate third-party APIs or legacy systems.
• Frontend Simplicity: Clients don't need to know about backend service boundaries.

You've learned the core concepts of GraphQL Schema Stitching. Let's test your understanding!

In this lesson, we explored Schema Stitching, a powerful technique to combine multiple GraphQL APIs into a single, unified API gateway. We saw how it helps manage microservices and simplifies the client experience by providing one endpoint for diverse data sources.

Next, we'll dive into the practical implementation of merging multiple GraphQL schemas in a Spring Boot environment.