同时使用GraphQL和REST
在不同层级的堆栈中使用GraphQL和REST以实现不同的目的
人们常说GraphQL 和REST是竞争性技术，并列出。虽然这些技术重叠，但大多数采用GraphQL的组织都将其用于不同目的和不同层级的堆栈。
此页面概述了
- 组织通常采用的方案
- GraphQL 最适合应用于哪种架构工具箱中
- 它能如何帮助制定弹性的API策略
传统的N层架构
在传统的N层架构中，系统至少包含三个层次：表示层、应用层和数据层。每一层都有其独特的作用：
- 表示层是客户与产品、体验以及API市场进行交互的地方。
- 应用层是服务和业务逻辑所在的地方，也是表示层应用程序访问数据的方式。
- 数据层存储有关贵公司、客户、产品等的数据。
然而，表示层和应用层之间的摩擦可能会阻止组织将产品和数据推向客户手中。
从应用层角度来看
"我们的工作是以最有效、最性能的方式公开我们所知道的一切，我们所拥有的全部数据，以及我们必须以最积极的方式交付的全部功能。客户端通过API末端的消费、聚合、协调和丰富我们的提供内容不是我们的工作。记住，分离关注点！"
从表示层来看，思路不同
"我们对访问的API既需要太多的聚合，又需要太多的协调，或者提供不了我们所需要的服务，运行得太慢，它们的数量太多，而且始终在未通知的情况下改变！"
表示层和应用层都处于不断变化之中。始终有新的客户端、新的数据访问和产品需求、新的数据、新的服务、新的业务逻辑和其他变化。
API策略目标
设定高级目标应该是决定贵组织API战略的一部分。常见的目标包括
- 提供快速自助服务
- 创建一个绝缘契约
- 放大现有投资
- 管理中间层
提供快速自助服务
任何API策略的关键目标都应该是使API消费者能够使用API。这意味着您的API消费者尽可能少地摩擦，能够更好地自助服务。
创建绝缘契约
您的API策略应该屏蔽API消费者从后端服务的复杂性。反之，策略应该绝缘上游客户端更改对下游服务的影响。
契约，API消费者与API通信的接口，应起到抽象的作用。
放大现有投资
任何API投资都应积极影响其当前和未来的用例。
管理中间层
API应该有一个明确的托管和治理模型，包括适当的利益相关者。
💡 提示
更多关于Supergraph托管的信息。
解决复杂性方法
组织经常使用客户端管理或前端后端（BFF）方法来处理表示层和应用层之间的复杂性。这些方法在实现弹性API策略的目标方面可能有限制。
客户端管理
在客户端管理方法中，每个应用程序直接与每个后端服务对话，创建了大量连接和依赖关系。
分析
许多API策略最初都是客户端管理的，但这种策略很快就会失控。每个客户端都是独立操作，导致不一致性和维护困难。
问题
- 没有实现关注点的分离
- "厚重型"客户端和不一致的用户体验
- 每次客户端重写都抛弃了逻辑
- 不是快速或自助服务
- 不是一个隔离的合同
- 不会放大现有投资
- 没有治理
前端对于前端API (BFF)
在Backend for Frontend (BFF)方法中，每个应用都有自己的专用 API，称为BFF。这个BFF特定于该应用，由应用团队维护，并负责满足该应用的数据编排需求。
分析
BFF可以为解决与客户端管理方法相关的一些问题提供一个可行的解决方案。BFF方法让消费者可以聚合来自许多后端API的数据。然而，随着你的组织添加越来越多的客户端，这种方法也可能失控。这尤其会成为使用微前端的组织的难题。保持可维护性和治理可能会变得更加具有挑战性。
问题
- BFF的数量可能会增加到难以管理的程度
- 不会放大现有投资
- 尽管API网关可以为BFF提供一些治理，但它仍然无法对数据检索提供很多治理
ⓘ 注意
您可能还需要除了GraphQL之外的一个BFF来处理您应用程序特有的"工具"端点。在这种情况下，您可以使用中继模式将数据获取和突变通过您的BFF传递到您的GraphQL层。使用GraphQL
当使用GraphQL时，所有应用都与应用的一个通用GraphQL中间层进行通信，然后该中间层协调调用下游数据服务。
这个中间层将表示层的需求翻译成应用层。由于本身性质，GraphQL是自我服务的。一个GraphQL模式充当隔离的合同，所有投资都会放大，因为所有消费者都受益于所有投资。它具有高度的可治理性，因为单个端点通过声明性策略公开了所有数据。
快速自助服务
✅ GraphQL使快速自助服务成为表示层客户端的可能，通过将一次性的手动编写的BFF API替换为声明性查询。
查询是在需求定义了表示层所需的，不考虑数据源。每个前端用例（如果你使用微前端，包括每个微前端）定义了一个声明性的查询以在一次请求中获取所需的所有数据。
GraphQL能够在不创建新端点的情况下实现需求驱动的API创建。每个客户端都向同一个端点发送请求，由一个查询策划器执行，并高效地分配到底层的应用和数据层。
创建绝缘契约
✅ GraphQL提供了一个隔离的合同来管理表示层和应用层之间的需求，它在管理持续变化的同时足够灵活，足够稳定以防止破坏性变化。
任何企业数据模型中最稳定的部分是推动业务的根本对象——例如，客户、订单或产品。即使定义它们的底层数据存储和服务模型被重建，这些对象仍然存在。
现代化意味着栈中的每个部分都有固定的寿命，并且每年都在缩短。答案是将这些实体建模在一个声明性层中，这个层不嵌入代码，可以生存并演进。
放大投资
✅ GraphQL不仅保留现有API的价值，还能通过联邦和连接和组合独立API的能力来放大投资。
GraphQL提供了一个抽象层，允许组织随着时间的推移添加新的数据实体和字段，而不会直接影响消费客户端。API客户端可以在API之间导航，而无需意识到他们正在从不同的团队、可能用不同语言编写、具有不同API协议等的API中检索数据。
所有对图的投资都能带来回报，因为它们为现有客户和潜在未来客户提供了价值。
治理
✅ GraphQL提供了一个声明性控制平面，这是您架构的关键中间层。
GraphQL允许组织将所有核心域实体集中到一个统一的层中，无需为每个客户端生成单独的端点，即可满足来自客户端的定制查询。这对于治理来说非常好，因为它为组织提供了一个单一、静态的位置来定义他们的整个API界面，而不是管理数百个端点。
结论
GraphQL与REST不竞争。相反，它最适合作为栈中新的一层，具有不同的目的——即连接表示层和应用层之间的差距。
GraphQL使组织能够推动一个有弹性的API策略，提供治理和所有权，同时减少摩擦，并通过自助服务允许API消费者提高其速度。
要一起使用GraphQL和REST：
- ✅ 使用REST进行后端数据服务
- ✅ 使用GraphQL作为中间层，聚合来自您后端数据服务的数据
- ✅ 使用GraphQL来抽象您的后端服务的实现细节