GraphQL 比 REST 更容易管理吗？

GraphQL 已成为现代环境中无处不在的技术。GraphQL 具有强大的功能、灵活性和可扩展性，并且具有高度可定制性。这种可定制性乍看起来似乎与 API 治理背道而驰，但事实真的如此吗？将 API 治理实际应用到 GraphQL 感觉如何？它比 REST 更容易治理吗？让我们来看看！

简要回顾

在深入研究 GraphQL 之前，我们先简要了解一下治理这个概念，看看 GraphQL 在上下文中所处的位置。简而言之，API 治理是组织可以设置的一组策略、过程、标准和实践，以帮助管理组织内 API 的一致性、稳定性和可用性。换句话说，治理描述了您的 API 应如何运作，并提供了一种确保它们遵循这些准则的方法。

为什么要治理？

API治理使企业能够更好地控制整个API生命周期，确保遵守可用性、可扩展性、稳定性和安全性标准。如果部署得当，治理策略可以成为推动组织成功的业务和目的用例的技术镜像。例如，如果您的服务旨在为安全环境中的不同用户提供高价值功能，那么适当的治理政策就能确保该声明中的所有要素都能得到正确的基础系统、流程和资源的支持。

值得注意的是，治理是在组织内全面制定标准的好方法。应用程序接口管理设定了对生态系统内 “可以 “的理解，通过这样做，可以指导新项目的创建，而不需要一致的关口和压力点。

是什么让它变得困难？

治理可能具有挑战性，因为它通常被视为与快速迭代截然相反。API 开发通常以 100% 的速度进行，而 API 治理就像一只坚定的手，在一旁拉住并说：”等一下”。正因如此，对于注重超高速增长的企业来说，实施治理往往具有挑战性。

另一个现实是，应用程序接口管理通常是以 “一刀切 “的方式实施的。然而，对于开发不同产品甚至针对不同用例的产品的团队来说，例外情况往往导致必须做出改变，从而破坏了 API 治理的根本目的。

API 治理还需要一定的流程监督。虽然 API 治理在开始时往往非常有力，但新的迭代、开发和快速原型设计可能会创造一种环境，让这些规则 “仅此一次 “被绕过，从而诱使开发人员忽略这些规则。这就引入了新的管理门坎和流程，破坏了 API 治理的主要优势，将无形的指导之手变成了一种 “老大哥”。

GraphQL VS REST

将 REST 与 GraphQL 进行比较非常有趣。REST 是一种标准范式，而 GraphQL 是一种查询语言。为了使比较公平，我们应该考虑一下典型的 REST 实现与 GraphQL 的比较。

GraphQL 和 REST 有很多相似之处。它们都是无状态的，围绕资源表示而设计，并与客户端-服务器模型保持一致。它们的数据结构在基本层面上通常是相似的，都支持相同的超媒体驱动的数据连接模型。因此，REST 和 GraphQL 经常被捆绑到同一个解决方案类别中。

然而，当你深入研究时，GraphQL 有一些独特的功能，使其比 REST 更容易管理。

GraphQL 定义明确且结构合理

GraphQL 具有强类型和声明式模式定义系统。强类型化意味着该系统具有非常具体的数据类型，实施过程中的每项数据都必须符合其对应的类型。除了声明式模式定义外，这还意味着 GraphQL API 在模式级别上定义明确，允许通过模式本身来执行大量策略。

此外，GraphQL利用了一种最能概括为图表的结构。该图代表了单个微服务的相互连接部分，并包含它所连接的其他微服务的关系。由于这种关系在微观和宏观层面上结构良好，因此 API 治理可以在细粒度和自上而下的层面上得到很好的执行。

从本质上讲，只需从一开始就精心设计，GraphQL 就能在很大程度上得到良好的管理。在这种情况下，模式就像服务器和客户端之间的契约，提供了一个清晰、稳健和受控的交互范例，偏离模式定义不会产生异常的 API 包含，它们只会被拒绝和拒绝。

GraphQL提供统一的管理点

GraphQL 的另一个独特之处在于端点的行为方式。在 RESTful 设计中，跨多个查询和系统收集数据需要多次查询和组合工作。这种多点查询带来了巨大的复杂性，但也需要实施更多的管理策略。

另一方面，GraphQL 在路由到内部系统或从组合源提供数据之前，通常通过单个入口点进行操作。这最终意味着，与 REST 所需的更多和更复杂的端点集合相比，GraphQL 治理只需关注一小部分端点。

GraphQL 具有很强的内省性

虽然 REST 有一些系统可以促进自省，但 GraphQL 在向客户端展示对其模式、数据和功能的理解方面具有独特的功效。在 GraphQL 中，系统希望被理解，因此从一开始就为整个系统的治理提供了清晰的地图。

注意事项

考虑到所有这一切，我们必须记住，虽然 GraphQL 因其强大的类型、声明性模式和强大的内部设计范例而通常比 REST 更容易治理，但一些考虑因素也会使治理与 REST 有所不同。

GraphQL 具有很高的灵活性，但这种灵活性意味着您需要考虑在哪些方面进行管理。当任何人都能以首选格式请求结构化数据时，您要么需要应用严格的控制来保护这些数据（这会对性能产生一些影响），要么需要主动设计数据以避免引入风险。

GraphQL 越大越复杂。虽然它能带来很高的效率，但更复杂的模式意味着治理的复杂性也会增加，从而使系统变得非常笨重。

管理 GraphQL 的最佳实践

考虑到这一点，在为 GraphQL 构建 API 治理时，我们可以采用哪些最佳实践呢？以下是为 GraphQL 引入健康治理模式的一些提示。

模式为王

说到 GraphQL，建立一个好的模式是重中之重。在 GraphQL 中实施 API 治理可能更容易，但如果创建的模式定义不清、考虑不周，也很容易搞砸。因此，定义明确的命名约定、类型、字段控制、关系等将大大有助于确保 API 治理的有效性。

要做到这一点，必须确保使用正确的工具。有效的设计和有效的模式需要经过验证、完全理解并能充分发挥潜力的标准和工具。

长期规划

只有遵循业务用例，基于模式的 API 治理才能取得成功。然而，业务用例是会变化的，那么如何才能确保您能够根据新的业务需求进行变更，而不会失去模式驱动治理的优势呢？

制定长期计划！在构建模式时，确保每个部分的设计都能适应变化和新模式。规划交流方式，确保适当的废弃和日落，并使用超媒体和元上下文在适当的地方提供替代和更新。确保您的模式能够适应新的需求，这样就能确保您的应用程序接口管理政策始终与用例相关。

杠杆联合

GraphQL 联合是在多个模式之间保持一致体验的好方法。联盟创建了一种 “模式网关”，将服务连接在一起，并指出每个模式在数据流中的位置。这可以利用元数据在服务之间提供更强大的功能和连续性。

从管理的角度来看，让开发人员在自己的子图上工作可能会造成一种情况，即他们的服务在符合治理规则的同时，也会产生名称碰撞和其他类似问题。因此，要有一个中央真相源，并确保团队之间的交叉沟通。利用文档和内部门户，确保团队创建的子图与模式相匹配，而不会与其他开发工作发生冲突。从长远来看，这将为您省去很多麻烦，并使系统更加健康。