GraphQL 模式缝合器

要解决的问题

随着服务拆分，同一个 GraphQL 能力可能散落在多个独立端点后面。客户端查询一个完整业务对象时，不得不串行或并行地访问多个服务，请求次数和延迟随之上升。每个子模式各自独立演化，类型定义容易重复，字段命名也可能冲突，团队间协调成本越来越高。

核心能力与工作流程

这个技能的目标是把分散的模式收敛成一个统一入口：

• 使用 graphql-tools 的 stitchSchemas 能力，把多个已有 schema 合并为一份可执行的统一模式。
• 遵循 Apollo Federation v2 的联合模型组织各子服务，把跨服务数据组装成客户端可见的单一图。
• 合并完成后，调用 rover graph check 对组合后的模式做校验，在部署前发现类型冲突、缺少 resolver 或联邦约束不满足等问题。

典型流程是：先完成各子服务的模式定义，再通过 stitching 合并为网关模式，最后用 rover 检查，通过后才对外发布。

适用边界与注意点

• GraphQL.js 是通用库，在 Node 服务中同时支持 CommonJS 的 require() 和 ESModule 的 import。运行环境里模块解析方式不一致时，需要确认引用路径能被正确加载。
• 模式合并不等于任意拼贴。联邦模式下，实体的解析、值对象的扩展都有明确约束，跨服务字段需要按规则声明来源。
• rover graph check 是合并后的验证环节，它不能替代各子服务对自身模式的独立维护。