翻译来源: The BFF Pattern (Backend for Frontend): An Introduction
想象一下这种场景，你需要使用微服务构建电子商务应用程序。这些微服务可能包含的有客户、订单、产品、购物车等微服务。这些微服务暴露 APIs 给前端使用。
然而返回给前端的数据可能无法按装前端需要的方式进行格式化或者进行筛选。
这种情况下，前端需要按照自己的逻辑格式化数据。但是如果这些写在前端，就会占用更多浏览器的资源。
在这种情况下， 我们可以使用 BFF 将前端逻辑移动到一个中间层。这个中间层就是 BFF, 当一个前端请求数据的时候，它将到达 BFF 的 API 层。
BFF 将进行如何下的操作
- 调用微服务相关的 API 获取包含所需的数据
- 根据前端的需要格式化当前的数据
- 将格式化当前的发送给前端
因此，前端可以达到最小的逻辑。因此，一个 BFF 能够有助于简化数据并承担前端提供精简接口的责任。
BFF 如何适用于电子商务网站示例？
下面的图表展示了每个微服务通过 BFF 与前端连接的方式。
BFF 的作用
正如我们已经讨论的，BFF 扮演者前端和微服务之家你的接口。事实上，前端团队应该负责管理 BFF。
单个 BFF 专注于单个 UI，并且仅限于 UI。因此，他将帮助前端的简洁性并且共通过后端查看统一的视图。
这带来了下一个问题，我们可以为多个 UI 使用多个 BFF 吗？我们在文章的后半部分回答这个问题。请继续阅读.😊
这会增加延迟吗？
现在我们知道，BFF 类似于客户端和其他的外部 API，服务等之间的代理服务器。如果请求必须通过一个组件，则会增加延迟，但是，这个与浏览器使用没有针对前端优化的服务相比，BFF 的延迟是微不足道的。
构建 BFF 允许您智能地批量调用其他后端/微服务，并一次性返回数据，或通过转换和格式化数据返回更便捷的表示。
这对于使用 2G 和 3G 网络的移动用户非常有用，因为连接需要 2s 或者更长的时间。
何时应该在您的应用程序中使用 BFF
跟其他的模式以一样，使用 BFF 取决上下和架构设计。例如，您的应用程序是一个简单的单体应用程序，使用 BFF 没有必要。它能添加的价值很少。
然而，如果你的应用程序依赖很多的无服务和外部 API 和其他的服务。最好使用 BFF 来简化数据流并未您的应用程序引入更高的效率。
进而，如果您的应用程序需要为后端接口提供的数据做大量的聚合操作，那么使用 BFF 是一个合适的选择。
我们可以使用多个 BFF 吗？
当然可以！这就是使用 BFF 的主要目的。
传统的方法（没有 BFF 的应用程序）会为所有客户端仅有一个 API 网关。示意图如下：
然而使用 BFF 的目的是为客户端提供一个专注的接口链接。例如，移动 UI 和浏览器的数据消耗可能不同。这种情况下，为了更好的数据表示，可以使用两个 BFF。让我们来看一个带有多个 BFF 的应用程序图表。
正如您所看到的，每个客户端都有一个 BFF。它将有助于优化服务（Sa、Sb...Sn）的响应。
BFF 的优点
以下是拥有 BFF 的一些优点：
- 关注点分离 --- 前端需求将被从后端的关注点分离出来。这更加易于维护。
- 更加易于维护和修改 API --- 客户端更加少的去关注 API 的数据结构，这将使它具有更加适应性的 API 弹性。
- 前端能够好的处理错误 --- 服务端的一些错误对前端来说是毫无意义的，BFF 客户端映射服务单的错误，而不是直接返回，这有助于用户体验提升。
- 多个设备类型可以并行调用后端 --- 当浏览器向浏览器专属服务器发送请求时，移动端的也可以发送同样的请求。这有助于更快的从服务器中获取想响应。
- 更好的安全性 --- 某些敏感信息可以被隐藏，向前端发送响应时可以省略不必要的数据。这种抽象会使攻击者更难以针对应用程序进行攻击。
- 分享组件团队的所有权 --- 团队之间，不同的团队处理不同的程序。前端团队可以共享可兑换程序以及其基础的消耗资源的所有权。以下是这种团队的 BFF 示例：
最佳实践
到目前为止我们所看到的很棒！但是，BFF 是否是无故障的呢？
答案是：不是~，像其他技术一样 BFF 也有缺点，为了避免这个问题我们需要遵循最佳实践。
- 避免在 BFF 中实现自包含的全部 API --- 自包含 API 应该在微服务层。在开始实现 BFF 时候，大多数开发者忘记了这一点。你应该记住 BFF 是客户端与服务端之间的翻译层。当服务端 API 返回数据的时候，他的目的是将数据转换成苦短指定的数据类型。
- 便面 BFF 逻辑重复 --- 一个重要的点要注意的是，一个 BFF 应该针对特定的用户体验，而不是设备类型。例如，大多数时候，所有移动设备（iOS，Android 等）共享相同的用户体验。在这种情况下，一个适用于所有操作系统的 BFF 就足够了。没有必要为 iOS 和 Android 分别设置不同的 BFF。
- 避免过度依赖 BFF --- BFF 只是一个翻译层。它确实为应用程序提供了一定程度的安全性。但是，你不应过度依赖它。无论是否存在 BFF，你的 API 层和前端层都应负责所有功能和安全方面。因为 BFF 应填补空缺，而不应向应用程序添加任何功能或服务。
- 为了实现更易于管理的面向微服务的后端（BFF）模式，一个好的实践是将每个微服务看作组件，并利用一种模块化、可重用和共享的方法来处理它们。
总结
BFF 模式不仅有助于开发，还可以大幅提升用户体验。因此，在保持 BFF 关注前端的同时，考虑数据优化和聚合非常重要。
此外，如果您以前没有使用过 BFF 模式，那么现在是开始的时候了。
