什么是BFF(Backends For Frontends)

顾名思义，它是前端的后端（服务器）。专门为前端而调用API，或者生成 HTML 的服务器。看到这里你可能会想，“这与传统的Web应用服务器有什么不同？”。本质上是一样的，只是专门为前端打造的这一点不同而已。

首先，Web应用服务器有如下几种用途：

• 从数据库和全文搜索引擎等中间件获取和更新数据
• 创建一个页面
• 作为HTTP接口从用户那里获取输入信息

在这里，从数据库和全文搜索引擎中获取和更新数据的部分旨在进行管理，同时确保数据的完整性和可靠性。构建页面的部分和获取用户输入信息的部分对应于用户界面（UI），目的是提升用户体验（UX）。

前者作为后端（Backends），而后者作为前端（Frontends），通过前后端的划分让开发者专注于各自的专业领域，这样的架构设计被称为“BFF”。

轮廓图如下所示

像这样，BFF往往采取“设置在反向代理和后端API服务器之间”的配置。反向代理是一个用来替代Web应用服务器，进行静态文件压缩和缓存的服务器。后端API服务器主要与数据库、全文搜索引擎等中间件配合，起到操作资源和管理数据的作用。

BFF负责UI/UX相关的功能，比如在这两个服务器之间建立一个页面，接受用户的输入信息并发送给后端。

BFF 产生的技术背景和历史背景

技术背景

在前端领域的快速发展状态下，前端的开发早已从MVC的传统模式转变为现如今的前后端分离架构。

MVC的开发模式中，前后端开发过分耦合，导致开发效率低下，分工不均。出于解耦的目的，提出了前后端分离的架构。前端通过AJAX调用后端接口进行交互，实现前后端项目分离。

随着前端领域的不断扩大，后端服务在复杂的前端业务背景下，为兼容不同的业务逻辑变得臃肿而难以维护。

在这样的背景下，后端微服务架构逐渐成熟，领域之间的解耦也成为后端服务的主流。然而，前端需要自身去实现数据的聚合、裁剪等功能。虽然我们可以通过前端去请求不同的服务器然后做数据的操作，但是由于不同的生态下，会存在一定的限制，例如微信小程序的域名数量限制。并且，服务的底层协议也会存在一定的限制，如RPC协议。为此，BFF中间层架构是一个比较不错的选择。

BFF(Back-end for Front-end) - 服务于前端的后端。

历史背景

在21世纪初，使用 JavaScript 进行 HTTP 请求的Ajax 通信概念开始普及，Web 应用逐渐变得丰富,且具有更强的交互性。随着富Web应用数量的增加，以及更多的处理集中在了客户端，服务器端越来越多地使用了仅发送和接收数据的 API 。

此外，随着除 Web 应用之外的客户端（例如移动应用）数量的增加，服务器端需要构建专注于某一个领域的 API。它已经演变为“专门处理特定资源的架构”，因为它被称为微服务。

但是，随着客户端的更加多样化，创建满足所有客户端需求的 API 服务器变得越来越困难。你创建的移动应用和 Web 应用，UI 也各不相同，不同的客户端上所需要展现的内容也可能不同。例如，你创建了一个 Web 应用，由于屏幕尺寸的不同，用户可以看到的信息不同 PC 和智能手机上可能会有所不同，甚至 UI 可能与移动应用完全不同。

此外，Web 应用具有环境限制，例如在 HTTP/1.1 可以同时请求的请求数限制为 6。

针对这些情况，出现了一种架构，将响应每个客户端请求的服务器放置在前端，充当与后端API服务器的桥梁。这是因为 BFF 具有构建 HTML 和减少请求数量等优点。

这样，一种叫做“BFF”的架构就诞生了。