0Pricing
GraphQL APIs with Spring Boot · Lección

Combinación de varios esquemas de GraphQL

Implemente schema stitching en un entorno Spring Boot para combinar y exponer varios servicios de GraphQL.

Combinación de varios esquemas de GraphQL es una lección gratuita de GraphQL APIs with Spring Boot en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de GraphQL APIs with Spring Boot, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de GraphQL APIs with Spring Boot incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

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.

Preguntas frecuentes

¿La lección «Combinación de varios esquemas de GraphQL» es gratis?

Sí — el texto completo de «Combinación de varios esquemas de GraphQL» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de GraphQL APIs with Spring Boot, actualiza a CoddyKit PRO. El curso de GraphQL APIs with Spring Boot incluye 4 lecciones en total.

¿Qué aprenderé en «Combinación de varios esquemas de GraphQL»?

Implemente schema stitching en un entorno Spring Boot para combinar y exponer varios servicios de GraphQL. Practicas GraphQL APIs with Spring Boot con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar GraphQL APIs with Spring Boot?

No se requiere experiencia previa. GraphQL APIs with Spring Boot en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.

¿Cuánto tiempo toma la lección «Combinación de varios esquemas de GraphQL»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de GraphQL APIs with Spring Boot?

Sí. Cada lección de GraphQL APIs with Spring Boot incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Creación de directivas personalizadas
  2. Fundamentos del schema stitching
  3. Combinación de varios esquemas de GraphQL
  4. Modularización de esquemas con extensiones de tipos
← Volver a GraphQL APIs with Spring Boot