GraphQL联邦条件依赖优化：如何按需调用子图减少请求？

问题背景 #

现有三个独立GraphQL子图：

• Subgraph 1：包含数据字段A和D
• Subgraph 2：包含数据字段B和D
• Subgraph 3：包含数据字段C和D

需求是：字段A的值需要根据D的取值，条件依赖Subgraph 2的B或Subgraph 3的C。但当前实现会同时触发两个子图的调用，造成不必要的资源占用和基础设施扩容压力，需要优化为仅按需调用对应子图。

当前实现的问题 #

当前Subgraph 1的Schema中，A字段通过@requires(fields: "B C")静态声明依赖外部的B和C字段，这会强制网关同时拉取Subgraph 2和3的数据，即使只需要其中一个。

当前代码示例 #

Subgraph 1 Schema

// Subgraph 1
type EntityHere @key (fields: "D"){
    D: boolean
    A: string @requires(fields: "B C") // 同时触发两个子图调用
    B: string @external
    C: string @external 
}

Subgraph 2 Schema

// Subgraph 2
type EntityHere @key (fields: "D") {
    D: boolean
    B: string 
}

Subgraph 3 Schema

// Subgraph 3
type EntityHere @key (fields: "D"){
    D: boolean
    C: string
}

Resolver 实现

// Subgraph 1 Resolver
EntityHere : {
    A: (reference, args, request) => {
        if(reference.D === "B"){
             return reference.B
        } else if (reference.D === "C"){
             return reference.C
        }
    },
}

// Subgraph 2 Resolver
EntityHere : {
    B: (reference, args, request) => {
        if(reference.D === "B"){
             var b = fetchB() // 调用B服务
             return b
        }
    },
}

// Subgraph 3 Resolver
EntityHere : {
    C: (reference, args, request) => {
        if(reference.D === "C"){
             var c = fetchC() // 调用C服务
             return c
        }
    },
}

优化方案 #

核心思路是移除静态的字段依赖声明，改为在Resolver中动态根据D的值请求对应子图，从而实现按需调用。

1. 修改Subgraph 1的Schema #

移除@requires和外部字段B、C的声明，因为不再需要网关预拉取这些数据：

// Subgraph 1
type EntityHere @key(fields: "D") {
    D: String // 修正类型：原boolean类型与判断值"B"/"C"不匹配，改为String更合理
    A: String
}

2. 调整Subgraph 1的Resolver #

在A的Resolver中，根据D的取值直接请求对应子图获取数据，替代原有的依赖预拉取字段的逻辑：

// Subgraph 1 Resolver
EntityHere : {
    A: async (reference, args, context) => {
        const { D } = reference;
        // 按需请求对应子图
        if (D === "B") {
            // 请求Subgraph 2获取B的值
            const subgraph2Result = await context.gateway.query(`
                query GetEntity($d: String!) {
                    entityHere(D: $d) {
                        B
                    }
                }`, { variables: { d: D } });
            return subgraph2Result.data.entityHere.B;
        } else if (D === "C") {
            // 请求Subgraph 3获取C的值
            const subgraph3Result = await context.gateway.query(`
                query GetEntity($d: String!) {
                    entityHere(D: $d) {
                        C
                    }
                }`, { variables: { d: D } });
            return subgraph3Result.data.entityHere.C;
        }
        // 处理D为其他值的默认情况
        return null;
    },
}

说明：这里需要确保Subgraph 1的Resolver能通过context访问到网关的查询能力，或者直接调用对应子图的API端点。

3. 保留Subgraph 2和3的原有实现 #

Subgraph 2和3的Schema与Resolver无需修改，它们仅在被主动请求时才会执行fetchB()或fetchC()，避免了不必要的资源消耗。

额外注意点 #

• 类型修正：原代码中D被声明为boolean但判断逻辑使用字符串值，属于类型不匹配问题，建议改为String类型避免潜在错误。
• 错误处理：在Resolver中添加try/catch逻辑，捕获子图请求失败的情况，保证服务稳定性。
• 网关适配：如果使用Apollo Gateway等工具，需确保网关允许子图间的查询调用，或通过配置实现子图的直接访问。

内容的提问来源于stack exchange，提问作者Vishwanath