在寻找更具弹性、可持续扩展和收缩的平台时，组织们认识到 GraphQL 的价值远超过传统 API。
译自 Wrangle API Sprawl with a Resilient Platform，作者 Andrew Carlson 是 Apollo GraphQL 的首席现场架构师。他是一位工程领导者，生活中热衷于收集经验和新的观点，并且在这个过程中积累了许多爱好。
如果你还没有听说过 API 的无序蔓延，即 API 和服务的不受控制的繁殖，那么到了 2024 年你就会听说了。根据最近的 F5 首席技术官办公室的报告，API 蔓延是指当 API 在没有包括治理和最佳实践的整体策略的情况下被广泛分布时发生的。随着人工智能驱动的体验的兴起，我们只会看到 API 数量进一步激增。Kong 的首席技术官兼联合创始人 Marco Palladino 最近写道：
“当 AI 与世界互动时，它通过 API 进行，这将基本上推动 API 数量的指数增长，因为越来越多的产品和服务希望能够被 AI 消费。”
如果不加以控制，这种指数增长的 API 创造必然会导致一种危险形式的技术债务。我们都习惯于购买和偿还技术债务。毕竟，它就像任何其他形式的债务一样：我们试图出于特定原因承担它。也许我们需要满足市场驱动的最后期限，或者我们遇到了意外的停机，需要解决，但是出于某种原因，我们发现自己在几个月甚至几年内都没有偿还这笔技术债务。
API 蔓延是一种危险的技术债务形式。它有来自托管和扩展一系列 API 的硬性成本，真实的安全风险以及由平台工程团队需要管理的大量 API 带来的增加的运营负担。然而，从根本上说，API 蔓延是平台不具备弹性的结果。
如何知道你是否拥有一个有弹性的 API 平台？以下是一个简单的试金石测试。如果明天有人来找你，问你支持一个新的客户体验需要什么，你会感到内心恐慌吗？你的思绪会立刻转向所有的上游依赖，你的团队已经管理的 BFF（后端服务为前端）或者部署新的一套 API 的流程吗？如果是的话，你的 API 平台可能就不够弹性。
当定义一个具有弹性的 API 策略的特性时，我们可以从我们计划给我们的平台施加的压力的角度来考虑，然后根据相似的属性进行分组。例如：
- 客户端团队如何了解 API 的变化？
- 服务器端团队如何与客户端团队合作？
- 我们如何同时支持和管理不同类型的 API？
- 当服务器端依赖发生变化时，我们如何防止意外的破坏性变化？
- 我们如何在不部署新的体验 API 的情况下添加新的展示客户端？
- 我们如何更有效地使用我们的 API？
- 我们如何完全理解我们系统中的数据以及谁在使用它？
- 我们如何对我们部署的服务应用一种原则性的方法？
综合起来，我们可以将这些特性分为四个关键特征，这些特征有助于增强我们的 API 平台的弹性：快速自助服务、隔离层、现有投资的放大和强大的治理。设计和构建具有这些特性的 API 平台是一种战略性的方法，可以管理我们已经面临的 API 蔓延，并在恶化之前加以解决。
我们构建 API 的目的只有一个：被使用。当被问及他们如何定义平台成功时，根据 2023 年 API 现状报告，58% 的受访者表示他们通过使用量来衡量成功。在我们的平台战略的核心是增加谁在使用我们的 API 的压力，我们需要让我们的 API 简单易用，便于发现和实施。
对于前端和产品团队自主发现可用服务的能力越强，他们设计和发布新体验的速度就越快，他们也能更好地就潜在功能差距提出明智的问题。
我们发货的东西第一次永远不会完美。即使它接近完美，技术、团队和业务都在不断变化和演进。无论是计划一个新的展示体验，制定底层记录系统的主要版本升级，还是响应常见的漏洞和暴露 (CVE) 事件，我们都需要一种在堆栈的不同层面规划动荡的方法，并制定一种在不干扰其他团队的情况下适应变化的策略。
随着我们的服务和展示体验即将更新，我们可以制定一项策略，通过寻找一个结合了松散耦合和松散契约优势的隔离层，来减轻这些技术迁移的风险。
API 是一项投资和承诺。除了设计和开发服务的初始成本外，还有多年的维护、升级以及许多团队与任何给定服务签订生产合同的内部锁定。我们必须找到方法，使我们已经拥有的服务和 API 的现有投资变得更加有价值。为了重写而抛弃我们已经拥有的东西并不切实际。
无论是通过寻找新的前端体验来实施我们今天已经拥有的服务，还是识别可重用的服务级领域，考虑如何放大我们现有投资是具有弹性的 API 策略的关键特征之一。
在考虑我们的 API 平台治理时，我们可以将讨论分为两个主要关注领域：数据治理和服务治理。数据治理涉及回答诸如“谁可以访问 PII？”和“哪些体验正在实施‘用户’服务？”等问题。另一方面，服务治理回答诸如“我们控制 API 蔓延的政策是什么？”和“我们识别和减轻僵尸 API 的流程是什么？”等问题。
无论我们实施何种 API 策略，都必须考虑到所需的数据和服务治理，以确保我们的 API 的未来安全，而不会损害可用性、速度和可靠性。
与大多数架构决策一样，设计一个能够在灵活性和稳定性之间完美平衡的 API 策略并没有一种单一的方法。在过去，我们曾试图通过诸如客户端端口编排或 BFF（面向前端的后端）等策略来管理这种复杂性。不幸的是，这些策略导致了我们今天看到的 API 蔓延，给团队带来了不断增加的运营负担。
这种 API 扩张，无论它们是 BFF、体验 API 还是定制微服务，都是平台僵化的一个症状，无法可持续地支持业务或客户团队的新请求。在寻找更具弹性的 API 平台，可以可持续地扩展和收缩时，包括 Wayfair、Volvo 和 Netflix 在内的全球组织都转向了 GraphQL。这些组织的团队已经意识到，GraphQL 不仅仅是另一个 API。通过诸如联合 GraphQL 等架构模式的进步，它是在展示层和服务层之间将中间层编码化的一种方式，可以推动弹性。
联合 GraphQL 使团队能够以更大规模提供 GraphQL 的好处，将 GraphQL 从仅仅是另一个 API 转变为位于现有服务之上的堆栈中的一层。这个图形图表提供了通过单个端点访问任意数量服务的能力。它还使团队能够在这些子图之间共享实体和领域模型。
与暴露一堆后端为前端 (BFFs) 或体验 API 不同，联合 GraphQL 为服务团队提供了一个中央平台，将任何服务贡献给图形，推动 API 弹性和管理 API 蔓延的清晰路径。