面向前端的后端模式(BFF)

Backend For Frontend API设计是一种为前端设计的专门后端API，主要是为解决常见的前后端API冲突。

让我们看一下常见API设计前端/后端冲突的三个示例，然后寻找解决它们的方法。

示例冲突＃1：响应的格式化

前端开发人员通常要求后端响应能满足特定结构以匹配屏幕设计。虽然在后端API中解决响应格式化要求似乎很简单，但可能会出现以下几种情况：

1.前端虚拟化需要以特定方式聚合的数据，从而减少构建屏幕所需的编码工作量。

2. 团队正在将现有屏幕迁移到以API为中心的新架构，并且不希望将10到100个屏幕进行重做才能匹配新的内容格式

团队之间为此争论响应格式工作到底应该是谁来实现？后端开发人员希望实现普通的JSON，JSON API，HAL，Siren，Hydra或其他格式，以实现稳定的和互操作性。而前端开发人员通常需要特定格式，才能更容易渲染这些数据。我被要求成为这些冲突中的决斗者。

超媒体驱动的有效载荷特别有趣，因为后端API可以通过嵌入相关资源摘要来设计用于移动消费。这可能导致n + 1查询等问题，因为客户端被迫为相关资源对超媒体链接进行遍历导航。让我们接下来研究这个冲突。

示例冲突＃2：由于n + 1 API调用导致的性能问题

你可能以前从n + 1个查询中遇到过数据库性能问题。当应用程序执行初始数据库查询，然后对第一个查询的每个结果执行新的数据库查询时，会发生n + 1查询问题。对于产生100个结果的查询，应用程序进行101次数据库调用。这不是构建Web应用程序最高效的方法。

虽然数据库n + 1查询可能会影响我们的Web应用程序性能几百毫秒左右，但由于网络延迟的增加，对API的影响要大得多。此外，API使用者通常需要编写大量工作来编写客户端代码以获取初始API响应，然后执行数十到数百个后续API调用以获取其他数据并构建必要的数据结构以驱动单个Web或手机屏幕。

n + 1 API调用的关键指标是一个问题：

1.目标设备具有有限的网络带宽，并且需要由后端API提供其他数据

2.开发人员设计了响应内容，但没有相关资源的摘要详细信息，迫使API客户端使用者自己解决问题。

与上面的示例＃1不同，此问题的影响不仅限于前端开发人员。相反，性能问题可能会暴露给客户，从而导致糟糕的用户体验和客户流失。

示例冲突＃3：以数据库为中心的API设计

当团队说他们使用REST作为他们的API时，它几乎可以说是任何东西。从RPC风格的API到构建超媒体REST以及介于两者之间的所有API - API设计可以有各种不同的方法。

一种流行的方法是使用API​​包装数据库。我不推荐这种方法，因为基于Web的资源通常需要代表更加系统的系统视角，并包含客户端的工作流程。

直接的CRUD-over-database方法确实带来了自己的冲突：

1. 紧密耦合到数据库模式，导致在重命名或删除列时更改API字段名称，

2. 缺少更高级别的工作流端点，强制执行多个API调用以实现目标（类似于上面的n + 1问题）

根据我的经验，这似乎是最常见的，因为API通常是从现有数据库自下而上设计的。然后，前端团队必须努力将以解决方案为中心的用户界面映射到以数据库为中心的API设计。但是，后端开发人员往往不愿意或无法进行适当的更改来优化完成所需的API调用。

通过分层API设计解决冲突

这场冲突的根源：

1. 前端团队希望通过要求响应内容符合界面设计并在适当的时候限制API调用，从而来减轻编码负担。

2. 后端开发人员希望优化端点以实现重用和快速开发

要解决这个冲突，我们需要找到一种方法来支持双方。这样做的常用方法是使用分层API设计。在微服务世界内，这通常被称为前端后端（BFF）模式。

BFF模式允许后端API保持原样，前端开发人员构建和使用新API以满足UI的需求。使用BFF模式有两种主要方法：

1.以应用为中心的方法：

由最终用户的用例驱动，通常与用户的工作流程相关。

传统的后端API则被视为较小的可组合端点，通过将这些较小的可组合端点组合到新API中来实现最终用户的用例需求。

这类似于传统的SOA或微服务

2.以设备为中心的方法：

由设备功能驱动（例如移动应用，网络），鼓励跨设备API重复代码，根据需要调整响应内容甚至行为，减少在不可靠网络如移动网络之间的往返次数。

这两种方法都支持将业务流程推向更靠近后端API所在的服务器层，并且有降低网络延迟的想法。这会将客户端网络流量减少到仅对BFF API进行一次或两次API调用，这对移动应用程序而言非常重要。

请谨慎应用前端后端（BFF）模式

Backend For Frontend API设计模式是团队解决冲突并确保API解决实际问题的有用工具。一个主要缺点是，这会创建另一个需要在应用程序生命周期内维护的API。对于大型组织而言，这可能不是问题; 但是，较小的团队可能很难跟上后端API和一个或多个前端API的变化。

另一个危险是这些分层API不像“旗舰核心”平台API那样被认真对待。安全性，文档，测试和设计方面的失误可能会蔓延到这些API中，从而使产品暴露出各种问题。最坏的情况是，个人身份信息（PII）可能在未经适当授权的情况下发布，或者行业/政府法规可能会受到损害。

在构建设备或以应用程序为中心的API以解决这些冲突时，请不要图省事，将所有的细节都要纳入API产品本身设计。