GraphQL APIs with Spring Boot · Lesson

Merging Multiple GraphQL Schemas

Implement schema stitching in a Spring Boot environment to combine and expose multiple GraphQL services.

Merging Multiple GraphQL Schemas is a free GraphQL APIs with Spring Boot lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the GraphQL APIs with Spring Boot learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Unifying Your GraphQL APIs

As your application grows, you might find yourself with multiple independent GraphQL services. How do you present them as a single, cohesive API to your clients?

This lesson will guide you through implementing schema stitching in a Spring Boot application. You'll learn to combine multiple backend GraphQL schemas into one unified endpoint.

Acting as a Gateway

A GraphQL Gateway acts as a central entry point for all your client applications. Instead of clients querying multiple services directly, they query the gateway.

The gateway knows about all backend GraphQL services.
It fetches their individual schemas.
It combines these schemas into a single, unified schema.
It then routes incoming client queries to the correct backend service and aggregates the results.

Setting Up Your Spring Boot Gateway

Let's start by creating a new Spring Boot project. We'll need a few key dependencies to build our gateway:

spring-boot-starter-web: For web capabilities.
spring-graphql: To serve our combined GraphQL API.
graphql-java: The core library for building and manipulating GraphQL schemas.

Add these to your pom.xml or build.gradle.

Pointing to Backend Services

Our gateway needs to know where the backend GraphQL services are located. We can configure their URLs, perhaps in application.properties or through a dedicated configuration class.

For example, imagine we have a UserService and a ProductService, each with its own GraphQL endpoint:

application.properties:
  graphql.remote-services.user-service.url=http://localhost:8081/graphql
  graphql.remote-services.product-service.url=http://localhost:8082/graphql

In a real application, these would be separate Spring Boot applications.

Fetching Remote Schemas via Introspection

Before we can combine schemas, our gateway needs to discover what fields and types each backend service offers. This is done using introspection.

GraphQL provides a special introspection query that allows you to ask a GraphQL server for information about its schema. The gateway will send this query to each backend service to get their Schema Definition Language (SDL).

Fetching Schema Definition Language

Here's a simple Spring Boot component that uses WebClient to perform an introspection query and retrieve the SDL from a remote GraphQL service. This SDL will later be used to build our combined schema.

package com.coddykit.gateway;

import org.springframework.stereotype.Component;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;

@Component
public class RemoteSchemaFetcher {

    private final WebClient webClient;

    public RemoteSchemaFetcher(WebClient.Builder webClientBuilder) {
        this.webClient = webClientBuilder.baseUrl("").build();
    }

    // Simplified introspection query for demo
    private static final String INTROSPECTION_QUERY_BODY =
            "{\"query\":\"query { __schema { queryType { name } } }\"}";

    public Mono<String> fetchSchemaSdl(String serviceUrl) {
        return webClient.post()
                .uri(serviceUrl)
                .bodyValue(INTROSPECTION_QUERY_BODY)
                .retrieve()
                .bodyToMono(String.class)
                .map(response -> {
                    // In a real app, you'd parse the 'response' JSON
                    // to extract the actual SDL. For this example,
                    // we'll return a basic placeholder SDL.
                    return "type Query { userCount: Int }"; // Example SDL from a remote service
                });
    }

    public static void main(String[] args) {
        // This main method is for illustrative purposes only.
        // In a real Spring Boot app, this component would be managed by Spring.
        System.out.println("RemoteSchemaFetcher component simulates fetching SDL.");
        System.out.println("It uses WebClient to send an introspection query.");
        System.out.println("Actual parsing of the introspection result is omitted for brevity.");
    }
}

Combining Schema Definitions

Once we have the SDL strings from all our backend services, we need to combine them into a single GraphQLSchema object. The graphql-java library provides tools for this.

Use SchemaParser to parse each SDL string into a TypeDefinitionRegistry.
Merge these TypeDefinitionRegistry objects.
Use SchemaGenerator with the merged registry to create the final unified GraphQLSchema.

This combined schema is what your gateway will expose to clients.

Merging Type Definition Registries

This example demonstrates how to combine two TypeDefinitionRegistry objects into one. This is the core step in building our unified schema.

package com.coddykit.gateway;

import graphql.schema.GraphQLSchema;
import graphql.schema.idl.SchemaGenerator;
import graphql.schema.idl.SchemaParser;
import graphql.schema.idl.TypeDefinitionRegistry;

public class SchemaCombiner {

    public GraphQLSchema combineSchemas(String userSchemaSdl, String productSchemaSdl) {
        SchemaParser schemaParser = new SchemaParser();
        
        // Parse individual SDLs into TypeDefinitionRegistry
        TypeDefinitionRegistry userRegistry = schemaParser.parse(userSchemaSdl);
        TypeDefinitionRegistry productRegistry = schemaParser.parse(productSchemaSdl);
        
        // Merge the registries
        TypeDefinitionRegistry mergedRegistry = new TypeDefinitionRegistry();
        mergedRegistry.merge(userRegistry);
        mergedRegistry.merge(productRegistry);
        
        // Generate the final GraphQLSchema
        SchemaGenerator schemaGenerator = new SchemaGenerator();
        return schemaGenerator.makeExecutableSchema(mergedRegistry);
    }

    public static void main(String[] args) {
        String userSdl = "type Query { user(id: ID!): User } type User { id: ID! name: String }";
        String productSdl = "type Query { product(id: ID!): Product } type Product { id: ID! name: String price: Float }";

        SchemaCombiner combiner = new SchemaCombiner();
        GraphQLSchema combinedSchema = combiner.combineSchemas(userSdl, productSdl);

        System.out.println("Combined Schema Generated Successfully!");
        // You can inspect combinedSchema.getTypeMap() to see merged types
        System.out.println("Query types in merged schema: " +
                           combinedSchema.getQueryType().getFieldDefinitions().size());
        System.out.println("Expected 2 query fields (user, product).");
    }
}

Routing Queries with DataFetchers

After combining schemas, when a client queries the gateway, the gateway needs to know which backend service should handle each field.

This is achieved using a Delegating DataFetcher. For each field in the stitched schema, this DataFetcher will:

Identify the original backend service for that field.
Construct a sub-query for that backend.
Send the sub-query to the correct backend service.
Receive the response and integrate it into the overall result.

This is the "runtime" part of stitching, where data is actually fetched.

Stitching Knowledge Check

You've learned about the key steps involved in merging multiple GraphQL schemas in a Spring Boot gateway. Which of the following is the PRIMARY reason for using a Delegating DataFetcher in a stitched GraphQL gateway?

Recap: Building a Unified API

Congratulations! You've learned the fundamental steps to merge multiple GraphQL schemas using Spring Boot:

Setup a Spring Boot gateway with necessary dependencies.
Configure remote backend GraphQL service URLs.
Introspect each remote service to fetch its Schema Definition Language (SDL).
Combine the SDLs into a single GraphQLSchema using graphql-java.
Implement Delegating DataFetchers to route client queries to the appropriate backend service at runtime.

This unified approach simplifies client interactions and provides a consistent API experience.

Frequently asked questions

Is the “Merging Multiple GraphQL Schemas” lesson free?

Yes — the full text of “Merging Multiple GraphQL Schemas” is free to read here on the web, and the GraphQL APIs with Spring Boot course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the GraphQL APIs with Spring Boot course, upgrade to CoddyKit PRO.

What will I learn in “Merging Multiple GraphQL Schemas”?

Implement schema stitching in a Spring Boot environment to combine and expose multiple GraphQL services. You practise GraphQL APIs with Spring Boot with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start GraphQL APIs with Spring Boot?

No prior experience is required. GraphQL APIs with Spring Boot on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Merging Multiple GraphQL Schemas” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this GraphQL APIs with Spring Boot lesson?

Yes. Every GraphQL APIs with Spring Boot lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Building Custom Directives
Schema Stitching Fundamentals
Merging Multiple GraphQL Schemas
Schema Modularization with Type Extensions

← Back to GraphQL APIs with Spring Boot