翻译来源: The BFF Pattern (Backend for Frontend): An Introduction

BFF(前端专属服务)：介绍

幻想一下这种场景，你需求运用微服务构建电子商务应用程序。这些微服务或许包括的有客户、订单、产品、购物车等微服务。这些微服务露出 APIs 给前端运用。

可是回来给前端的数据或许无法按装前端需求的方式进行格式化或许进行挑选。

这种情况下，前端需求按照自己的逻辑格式化数据。可是假如这些写在前端，就会占用更多浏览器的资源。

在这种情况下， 咱们能够运用 BFF 将前端逻辑移动到一个中间层。这个中间层便是 BFF, 当一个前端恳求数据的时分，它将抵达 BFF 的 API 层。

BFF 将进行怎么下的操作

  • 调用微服务相关的 API 获取包括所需的数据
  • 根据前端的需求格式化当时的数据
  • 将格式化当时的发送给前端

因而，前端能够达到最小的逻辑。因而，一个 BFF 能够有助于简化数据并承当前端供给精简接口的职责。

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(前端专属服务)：介绍

可是运用 BFF 的意图是为客户端供给一个专注的接口链接。例如，移动 UI 和浏览器的数据耗费或许不同。这种情况下，为了更好的数据表明，能够运用两个 BFF。让咱们来看一个带有多个 BFF 的应用程序图表。

BFF(前端专属服务)：介绍

正如您所看到的，每个客户端都有一个 BFF。它将有助于优化服务（Sa、Sb…Sn）的呼应。

BFF 的长处

以下是具有 BFF 的一些长处：

  • 重视点分离 — 前端需求将被从后端的重视点分离出来。这愈加易于保护。
  • 愈加易于保护和修改 API — 客户端愈加少的去重视 API 的数据结构，这将使它具有愈加适应性的 API 弹性。
  • 前端能够好的处理过错 — 服务端的一些过错对前端来说是毫无意义的，BFF 客户端映射服务单的过错，而不是直接回来，这有助于用户体会提升。
  • 多个设备类型能够并行调用后端 — 当浏览器向浏览器专属服务器发送恳求时，移动端的也能够发送同样的恳求。这有助于更快的从服务器中获取想呼应。
  • 更好的安全性 — 某些灵敏信息能够被隐藏，向前端发送呼应时能够省掉不必要的数据。这种抽象会使攻击者更难以针对应用程序进行攻击。
  • 分享组件团队的一切权 — 团队之间，不同的团队处理不同的程序。前端团队能够同享可兑换程序以及其基础的耗费资源的一切权。以下是这种团队的 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 形式，那么现在是开始的时分了。