单体应用很简单。浏览器向 webapp 端点发送请求；后者从数据库中获取数据并返回响应。
移动客户端与微服务的兴起破坏了这种简单性，这篇文章中讨论一种处理复杂性的解决方案。
系统架构的复杂性增加
1、移动客户端的显示区域更小：平板电脑更小，手机更小。
一个可能的解决方案是返回所有数据并让每个客户端过滤掉不必要的数据。不幸的是，移动客户端也受到带宽较差的影响。并非每部手机都具有 5G 功能。
因此，过度获取数据不是一种选择。每个客户端都需要不同的数据子集。使用单体，可以根据每个客户端提供多个端点。
也可以在最前面设计一个具有特定层的网络应用程序，这种层检测发出请求的客户端并过滤掉响应中的不相关数据，Web 应用程序中的过度获取数据就能解决。
2、如今，微服务风靡一时。
微服务背后是两个披萨团队的想法。每个团队都是自治的，负责单个微服务或单个前端应用程序。为了避免开发工作之间的耦合，每个微服务团队都会发布其 API 合约并非常小心地处理更改。
每个微服务都需要为每种客户端提供严格必要的数据，以避免上述过度获取数据问题。微服务数量少，每一个都根据客户端过滤数据很麻烦；微服务的数量就很多，这显然是不可能的。
微服务数量和不同客户端数量之间的笛卡尔因子使得每个微服务上的专用数据端点成倍地昂贵。
解决方案：后端之前端BFF（Backend For Front-end）
BFF背后的想法是将逻辑从每个微服务转移到一个专用的“可部署端点”，这个“可部署端点”负责以下功能：
- 从每个所需的微服务中获取数据
- 提取相关部分
- 聚合它们
- 最后以与特定客户相关的格式返回它们
开发客户端的同一个团队开发客户端及其相关的 BFF。
BFF 提供与微服务相同的权衡：通过增加系统复杂性来提高开发速度。
BFF单独的部署单元与 API 网关比较
API 网关是所有客户端进入系统的单一入口点，而 BFF 是负责单一类型的客户端。
但是，API 网关模式有时也称为“前端之后端”
API 网关服务会根据客户端应用程序的不同要求而不断发展，最终，由于这些不同的客户端需求，它本身也会变得臃肿，就又变成一个大的单体服务，因此，建议将 API 网关拆分为多个服务或多个较小的 API 网关，例如根据每个客户端的类型对应一个，这样API网关就变成了BFF。
最关键的一点是，负责前端的团队也要对 BFF 负责。无论是单独的部署单元还是 API 网关配置的一部分，都是实现细节。
例如，使用 Apache APISIX，每个团队都可以将他们的 BFF 代码独立部署为单独的插件。
结论
每个客户短团队负责他们专用的 BFF：当客户端更改其数据需求时，团队可以部署适应新需求的新 BFF 版本。
BFF 是一个概念性解决方案，它可以是 API 网关中的专用部署单元或插件。
