阿波罗联邦简介
学习如何将您的 GraphQL API 合并成一个统一的超级图
阿波罗联邦是什么?
阿波罗联邦 让您可以声明性地将多个 GraphQL API 合并成一个单一、联合的图。这个联邦图让客户端可以通过单个请求与多个 API 交互。
客户端向联合 图 的单个入口点发出请求,称为 路由器。路由器智能地协调和分发请求,并在您的 API 中返回统一的响应。对于客户端而言,查询路由器的请求和响应周期看起来与查询任何 GraphQL 服务器相同。
💡 小贴士
要开始构建联合 GraphQL API,请查看 阿波罗联邦快速入门指南。
联邦的优势
微服务架构
阿波罗联邦让 API 团队可以在 微服务架构 下运行,同时向客户端公开统一的 GraphQL API。了解这些概念可以帮助您充分利用联邦。
💡 小贴士
- 了解关于 GraphQL 的考虑因素和好处。
- 了解关于 微服务架构的考虑因素和好处。
保持客户端的简单性和性能
在与多个非联邦的 GraphQL API 交互时,客户端可能需要发出多个请求。这可能会发生在采用 GraphQL 的组织有多个团队独立开发 API 的情况下。每个团队都会设置一个 GraphQL API,提供该团队所需的数据。例如,一个旅行应用可能会有为用户、航班和酒店分别设置的 GraphQL API:
使用单个联邦 graph,您可以保持 GraphQL 对传统 REST API 的一个强大优势:通过单个请求获取所有所需数据的能力。
router 会智能地调用它需要完成请求的所有 API,而不仅仅是转发它们。出于性能和安全的原因,客户端应该只向 查询 router,而只有 router 应该查询组成部分 API。无需配置任何客户端设置。
大规模设计模式
一些合并 GraphQL API 的替代方法会对您的模式施加限制,例如添加命名空间或用 ID 而不是类型来表示关系。使用这些方法,您的单独 GraphQL API 模式 可能看起来没有改变——但客户端与之交互的结果是更复杂的联邦模式,这需要您在前后端进行更改。
使用 Apollo Federation,客户端可以像交互一个单体一样交互联邦模式。您的 API 的消费不应知道或关心它是以微服务实现的。
维护单个 API
在联邦化中,每个团队直接向整体联邦 GraphQL 模式 做出贡献。每个团队可以独立工作而无需维护多个 API 层。这使您的平台团队能够专注于 API 的质量,而不是使其保持最新状态。
下一步
在继续之前,了解一些术语很重要
- 在结合多个 GraphQL API 时,单个联邦 graph 被称为 supergraph。
- 在 supergraph 中,单独的 GraphQL API 被称为 subgraphs。
在同一超图中,不同的子图可以使用不同的服务器实现,甚至可以使用不同的编程语言,只要它们是联邦兼容的。
其他资源
根据你的目标,你有多种方式来了解更多关于联邦的信息
如果你是联邦架构的初学者,这篇概述文章可以让你熟悉这些概念。
如果你想复习Apollo Federation的关键概念,下面这个视频给出了很好的概述。
如果你通过实践学习最好,这篇交互式教程教你使用Apollo Federation构建示例超图。
更多文档
一旦你准备好将联邦应用到自己的API中,这些文档部分可以帮助你入门
- 快速入门,让你开始使用联邦图。
- 联邦模式的概念概述Federated Schemas
- 参考资料
最佳实践
无论是你的超图实现已经开始还是在开始,你都可以使用超图架构框架(SAF)来了解最佳实践。SAF包括一个评估,以量化你的超图的当前状态并确定改进领域。