GraphQL采纳模式

GraphQL如何获得支持

当开发人员开始实验时GraphQL，他们通常从一个基础架构开始，其中客户端应用程序查询单个GraphQL服务器。然后，服务器将这些请求分发到后端数据源，并以客户端需要的形状返回数据：

随着不同团队开始采纳GraphQL，他们的方法通常类似于这种基本架构，但实现细节可能会因团队而异。在Apollo，我们通常看到这些初步、未整合的努力类似于以下四种模式之一：

模式1：只使用客户端GraphQL

急于利用GraphQL
的以客户端为中心的数据获取能力的客户端团队可能会首先在自己的应用程序上下文中实现GraphQL API。在这种类型的实现中，团队通常出于将现有API封装在单个GraphQL API端点中的便利性的动机而采纳GraphQL。

为了说明这种方法，只使用客户端GraphQL
的架构可能看起来像这样：

模式2：前端后端

GraphQL
通常被采用前端后端（BFF）模式的团队采纳。BFF试图解决不同的客户端（例如，网页和iOS）需要与一个单一的、通用的API交互的问题。或者，BFF可以节省客户端应用程序多次请求后端服务以获取渲染特定用户界面视图所需的所有数据。

作为解决方案，bff（bff）为每个客户端添加了一个新的层级，其中每个客户端都有一个专用的bff服务，该服务直接接收客户端的请求，并与用户体验紧密耦合。对于创建bff服务的团队，GraphQL可以天然地适合构建这个以客户端为中心的中间层，采用这种模式可能是向整合图迈出的重要第一步。

在实际中，bff与GraphQL模式可能如下所示：

模式3：单体

单体模式可以有两种形式

• 团队共享一个用于GraphQL服务器（一个或多个客户端使用）的代码库。在某些情况下，客户端代码甚至可能存储在同一个仓库中，与GraphQL服务器相同。无论如何组织代码，这个图的所有权都由为图做出贡献的各个开发者共享。

• 一个团队拥有一个GraphQL API，该API被多个客户端团队访问。这个团队通常定义了一套图的标准，并在全组织中推广其采用。

就像基于GraphQL的bff一样，维护单个单体GraphQL API可以帮助为组织有效整合GraphQL重点任务奠定基础。

对于任何单体场景，其高级架构看起来像这样

模式4：多个重叠的图

企业团队可能还会同时独立开发自己的服务专用GraphQL API。采用这种方法，团队可能会根据类型或用例来划分每个服务的API，但由于数据的互联性质，图之间通常存在重叠。

这种架构的一个例子可能如下所示

这些模式在哪里失效？

在评估谁在您的公司使用GraphQL以及如何使用之后，各个团队实施的模式可以提供关于他们最初试图解决的问题类型的洞见。同样，这些选择也有助于突出团队在技术堆栈中目前面临的哪些GraphQL痛点。

客户端只用的GraphQL

选择仅使用客户端GraphQL方法的团队希望通过在REST端点或必须与之协作的其他旧API之上分层GraphQL来提高他们的客户端开发体验。尽管改善开发者体验是一种胜利，但在这种抽象层下面，客户端应用程序仍然会因为负责向各种服务多次发送请求以收集所有渲染视图所需的数据而承担性能成本。

BFFs

与仅使用客户端的方法一样，使用GraphQL和bff的团队可以享受到改善的开发者体验的优势，并且他们还成功克服了仅使用客户端方法引起的性能问题。bff通过为客户端应用程序提供一个统一的接口来发送其请求，同时代表客户端处理多个后端服务的查询。

然而，构建和维护bff存在固有的权衡。当每个客户端团队都获得能力以创建满足其需求的bff时，这些团队之间不可避免的会存在重复劳动。或者，为了减少重复，在与看似相似客户端共享bff的情况下，由于缺乏明确的归属，包GraphQL模式可能变得过大且复杂。

单体

从共享最佳的线程（BFF）中产生的挑战在与具有共享所有权的一致性 （GraphQL服务器）联合。图的一部分可能被设计为仅满足特定客户团队的需求，而其他客户必须找到解决方法或为自用创建重叠的类型。同时，由于图的结构在客户端或特性层面盲目演变，标准化成为一个问题。

即使是当一个专门的服务器团队维护对图的所有权时，当单个产品需要多个图定义来支持多个客户的需求时，挑战很快就会出现。服务团队也可能发现自己肩负着构建和维护必要工具的任务，以随着时间的推移演进来满足新产品的需求，而不打破任何正在从图消费数据的客户端的兼容性。

多个重叠的图

最后，当一个企业内部存在多个图时，通常表明该组织是GraphQL的早期 adopter，迅速推进到生产阶段，并且随着时间的推移在GraphQL上投入了更多。这种投资的一个潜在结果可能是一个努力，试图将单一的研发GraphQL API扩展到各个团队，但最终可能导致了图被拆分为多个部分，以适应各个团队的需求。这种方法不可避免的结果是重叠图管理的重复工作量增加，并且客户端应用的用户体验不佳，不再具有统一的界面来请求数据。

不一致性：常见的缺点

上面描述的所有模式都有共同的缺点：它们的实现导致了一致性的缺乏。为了从他们的 GraphQL 架构中寻求更高的效率和可理解性，团队更有效的前进方式通常有两个要求：

• 消费者应能够期望在获取数据时保持一致性。应该向客户端应用程序公开一个单一的端点，并且，无论底层服务提供什么数据，客户端应该能够使用一致的流程来消费数据。

• 服务提供商应以便于消费的方式一致地表示常见实体。团队可能在数据层可以使用任何底层技术，但访问这些数据应通过GraphQL API整合，并以补充客户端场景的方式暴露。此外，团队应根据职责分离（而不是类型分离）划分服务边界，而不互相干扰。

超图如何解决这些挑战

将您的图整合为一个超图是克服这些架构陷阱、实现一致性和在企业中充分发挥 GraphQL 潜力的关键。

在根本层面上，向 supergraph 发展要求您的组织拥有一个统一的图，而不是由每个团队创建和管理的多个图。然而，这个通用图的实现应该在多个团队之间进行联邦。这是在 Principled GraphQL 中概述的第一个两个 "完整性原则"。

具体来说，向这种类型的一体化 graph 发展可以使企业内不同团队：

• 有效地扩展 GraphQL API：实施统一实践使得公司内可以在规模上实现 GraphQL 的好处。例如，团队可以更好地了解他们必须遵循的工作流程和政策来贡献到图中。同样，他们还可以从消费公共图数据时的改进标准化中受益。

• 获得您的数据统一视图：您的 graph 是您产品数据的表示。这种数据的整合视图为您提供了新鲜的角度来了解当前数据的使用情况，同时也启发了对未来如何使用此数据的创新应用。此外，它还有助于您在客户端应用程序消耗该数据方面强制实施一定程度的一致性。

• 利用现有基础设施： GraphQL 整合使团队能够在组织中复用现有基础设施，消除团队与数据交互时的重复工作。整合还使您能够全面了解每个团队开发的涉及您的图的实践和工具，并在整个公司范围内利用这些个体努力的优点。

• 更快地分发代码：公司采用 GraphQL 来更快地构建和迭代产品。随着 GraphQL 在团队中得到推广，这些好处可能会部分被用于开发支持该增长的工具所花费的时间所抵消。整合通过为团队提供清晰定义的做法，帮助回收这种失去的势头，当它们贡献或从图中消费数据时可以遵循这些做法。

supergraph 看起来像什么？

由联邦驱动的整合、超图架构由以下组成：

• 一系列 子图服务，每个服务都定义了一个独特的 GraphQL 模式
• 一个 路由器，该路由器将不同的模式组合成一个 超图并在图中执行查询

联邦使用声明式编程模型，使每个 子图只实现它负责的您图形的部分。这种方法可以使公司能够将企业规模的图表示为一组单独维护的 GraphQL 服务。

许多 GraphQL 库和框架支持联邦子图规范，因此无论您的技术堆栈如何，都可以采用 supergraph。

GraphOS 路由器是 Apollo 的下一代图运行时，它提供了快速且一致的性能，使联邦 超图 成为可能。