如何在GraphQL federation架构下实现Relay node query并解决校验问题

方案1：使用Apollo Federation 2.x的@interfaceObject指令 #

这是官方原生支持的跨子图接口实现方案，仅需要修改节点解析服务的Schema定义，给Node接口添加@interfaceObject标记即可：

interface Node @interfaceObject {
  id: ID!
}

type Query {
  node(id: ID!): Node!
}

添加该标记后，Apollo Gateway会自动识别该服务为Node接口的公共实现方，无需节点服务感知其他子图的Node实现类型。网关会自动拆分查询计划：节点服务仅负责解析node根字段、返回id和__typename，具体类型下的字段请求会被网关自动路由到对应子图处理，不会出现类型不识别的校验错误。

方案2：动态注册Node实现类型空存根（适配Federation 1.x场景） #

如果暂时无法升级到Federation 2.x，可以利用Netflix DGS的动态类型注册能力轻量化解决问题：

• 服务启动时从联邦Schema注册中心拉取全量联合Schema，解析出所有实现了Node接口的类型列表
• 通过DGS的RuntimeWiringConfigurer接口，动态将这些类型注册为节点服务的Schema类型，仅需要保留implements Node声明和id字段定义，无需同步其他业务字段
• 查询校验时，节点服务可以识别这些类型的存在，同时因为请求中仅查询id和__typename两个字段，完全符合存根Schema的定义，不会触发校验错误
  该方案比全量动态生成节点服务Schema的实现成本低很多，同时也不需要关闭校验，符合安全要求。

内容的提问来源于stack exchange，提问作者Lukáš Křečan