如何不改动前端即可拆分大型AppSync并整合多团队小型AppSync实例

合并schema方案的冗余问题 #

你预想的将全量子实例schema同步到主AppSync的方案，确实会产生schema重复维护的问题：主侧需要保留所有子实例的全量类型、字段定义，每个子实例的schema发生变更时，你都需要手动同步更新主侧的对应配置，维护成本随子实例数量上升快速增长，还容易出现两侧schema不一致的问题。

无需访问私有resolver的低维护整合方案 #

你不需要直接调用子实例的私有resolver，只要能访问子实例的公开GraphQL端点即可，推荐以下两种落地性最高的方案：

• Apollo Federation 原生整合（优先推荐）
  目前AWS AppSync已经原生支持Apollo Federation规范，你只需要让各小型AppSync实例开启Federation支持，将自身声明为Federation子图，你的主AppSync作为超图网关即可。
  这种模式下主AppSync不需要手动维护全量子图schema，AWS会自动拉取所有子图的schema并完成合并，请求也会自动路由到对应子实例执行，你只需要给主AppSync配置访问各子实例端点的权限（IAM角色、API密钥均可），全程不需要接触子实例的私有resolver，几乎没有额外维护成本。
• 自动化同步+HTTP数据源代理方案
  如果下游团队不愿意修改现有AppSync配置开启Federation，你可以搭建自动同步流水线解决schema重复维护问题：
  1. 定时调用各小型AppSync的introspection接口拉取其公开SDL
  2. 用自动化工具合并所有SDL生成主AppSync的全量schema
  3. 批量生成对应字段的HTTP resolver配置，指向对应子实例的公开端点
     整套流程可以嵌入CI/CD自动执行，不需要手动维护重复schema，同样不需要访问子实例的私有resolver。

选型建议 #

如果跨团队对齐成本较低，优先选择Federation原生方案，后期的维护成本最低；如果下游团队无法配合修改配置，选择第二种自动化同步方案即可满足需求。

内容的提问来源于stack exchange，提问作者Joey Yi Zhao