1. 联邦简介
4m

概述

欢迎来到航程,这是一个关于构建的 3 部分 系列,全部关于使用 构建

Apollo 联邦 是用于创建模块化 的一种架构。这意味着你的图是通过更小的、协同工作的部分构建起来的。当你的图使用这种架构构建时,它被称为 超级图。该 改善了团队的开发体验,使扩展产品变得更加容易。

为了安全地构建、管理和扩展我们的 ,我们将使用 Apollo GraphOS 平台。我们将使用 等工具将我们的 变为现实!

检查你的计划:本课程的一部分涵盖了自托管的 GraphOS 路由器,这需要 GraphOS 企业版计划。如果你所在的组织使用的是其他计划,你仍然可以跟着学习,但无法完成某些动手任务。你也可以通过注册免费的企业版试用.

在本第一课中,我们将初探联邦的世界。我们将探索 是什么,为什么它有用以及 架构的关键部分。在学习的过程中,我们将通过为名为 FlyBy 的旅行评论应用程序构建超级图来将这些概念付诸实践。

准备好了吗?让我们开始吧!在本课中,我们将

  • 指定 与非联邦图的不同之处
  • 识别 架构的关键部分
  • 解释使用模块化 的好处

注意: 本系列面向 后端开发人员


如果你只在前端工作,好消息是,无论后端是否使用联邦,你的工作流程都保持不变。你仍然会将所有 发送到单个端点,而 会处理其余操作!

Apollo 联邦之前的生活

在我们深入了解如何构建 的细节之前,让我们退一步看看没有 的生活是什么样的。

在非联邦架构中,整个 的所有类型和 都由 上的单个架构文件表示。

An example schema for a non-federated graph. All types and fields are defined in a single file called 'schema.graphql'.

当客户端需要一些数据时,它会向服务器发送 。然后服务器使用其架构、 解析请求的 ,将所有数据打包在一起,并将其发送回客户端。

A GraphQL server receives requests from clients and resolves them

对于较小的项目或团队来说,这很有效,但当你的架构增长时会发生什么?随着越来越多的类型和 被添加到该单个架构文件中,它变得越来越难以管理。后端团队可能会遇到更频繁的合并冲突和更长的开发时间。

但别担心!这就是 存在的意义所在。

注意: 你可能会听到“”和“联邦图”这两个术语可互换使用。它们的意思相同:你的图的功能划分为更小的、模块化的图。

超级图的结构

让我们仔细看看 的结构。超级图有两个关键部分:

  • 一个或多个 s
  • 一个

子图

中,你的架构是通过更小的部分构建的。这些部分的划分通常基于领域或哪个团队管理架构的这部分。

下面的示例显示了我们可以将架构拆分为两个部分:一部分用于与产品数据相关的 (name, numberInStock, price) 以及另一部分用于与事件数据相关的 (date, attendees, venue)。

The same example schema from earlier, but with the type definitions split across two schema files: products.graphql and events.graphql.

架构的每一部分都由一个单独的 拥有。一个 子图 是一个独立的 ,具有自己的架构文件、

An illustration of two subgraphs, with each subgraph having its own schema file, resolvers and data sources.

注意: 如果你之前使用过微服务架构,这可能看起来很熟悉。你可以将 看作是围绕你的微服务架构设计你的图架构的一种方式。

路由器

一个 架构还包括 路由器,它位于客户端和 之间。 负责接收来自客户端的传入 并将它们拆分为更小的操作,每个操作都可以由单个子图解析。

The journey of a GraphQL operation, in a supergraph with the router and subgraphs

超级图模式 的帮助下完成这项工作。 由来自每个 的所有 和类型组成。(在本课程的后面,我们将深入探讨 以及 如何解析客户端请求。)

有点像地图,帮助 确定哪个 可以解析 中的每个

为什么要使用 Apollo Federation?

使用 架构,从客户端的角度来看没有任何变化。它们仍然与单个 端点( )通信,并且它们不需要了解图的内部构建方式。

真正的优势在于后端。这些优势来自 的核心原则之一: 关注点分离

通过将我们的模式拆分为 ,后端团队可以独立地处理自己的子图,而不会影响正在处理 其他 的开发人员。由于每个子图都是一个独立的服务器,团队可以灵活地选择最适合他们的语言、基础设施和策略。

Three separate subgraphs, each with its own schema file. Developers can build, test, and deploy each subgraph separately.

练习

注意: 在每个课程的最后,您会发现一个 练习 部分,让您有机会检验自己对新概念的理解。

以下哪些是使用 Apollo Federation 的优势?

下一步

最好的方法是自己动手尝试。

在下一课中,我们将转向本课程的演示应用程序:我们名为 FlyBy 的旅行评论平台。

下一步

分享您对本课程的疑问和意见

您的反馈有助于我们改进!如果您遇到问题或困惑,请告诉我们,我们会帮助您。所有评论都是公开的,必须遵守 Apollo 行为准则。 请注意,已解决或已处理的评论可能会被删除。

您需要一个 GitHub 帐户才能在下方发布。没有? 请在 Odyssey 论坛中发布。