GraphQL APIs with Spring Boot · درس

دمج مخططات GraphQL متعددة

طبّق schema stitching في بيئة Spring Boot لدمج خدمات GraphQL متعددة وإتاحتها.

الدرس 3 من 411 خطوة

دمج مخططات GraphQL متعددة درس مجاني في GraphQL APIs with Spring Boot على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في GraphQL APIs with Spring Boot، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة GraphQL APIs with Spring Boot 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

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.

البدء مجانًا

تعلم GraphQL APIs with Spring Boot مع معلم ذكاء اصطناعي — مجانًا

اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.

الدورات: 12
الدروس: 48

ابدأ التعلم مجانًا عرض الدورة الكاملة

الأسئلة الشائعة

هل درس «دمج مخططات GraphQL متعددة» مجاني؟

نعم — نص درس «دمج مخططات GraphQL متعددة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة GraphQL APIs with Spring Boot، انتقل إلى CoddyKit PRO. تتضمن دورة GraphQL APIs with Spring Boot 4 دروس في المجموع.

ماذا ستتعلم في «دمج مخططات GraphQL متعددة»؟

طبّق schema stitching في بيئة Spring Boot لدمج خدمات GraphQL متعددة وإتاحتها. تتمرن على GraphQL APIs with Spring Boot مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ GraphQL APIs with Spring Boot؟

لا تُشترط خبرة سابقة. GraphQL APIs with Spring Boot على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «دمج مخططات GraphQL متعددة»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس GraphQL APIs with Spring Boot هذا؟

نعم. كل درس في GraphQL APIs with Spring Boot يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى GraphQL APIs with Spring Boot