想象一下，你需要使用微服务构建电子商务应用程序。你可能需要为客户、订单、产品、购物车等微服务创建API，这些微服务公开API供前端使用。
然而，由微服务返回给前端的数据可能不是按照前端所需的确切方式格式化或过滤的。
在这种情况下，前端需要自己编写一些逻辑来重新格式化这些数据。在前端拥有这样的逻辑将使用更多的浏览器资源。
在这种情况下，我们可以使用BFF来将一些前端逻辑转移到中间层。中间层是BFF。当前端请求一些数据时，它将调用BFF中的API。
BFF将执行以下操作：
- 调用相关的微服务API并获取所需数据
- 根据前端表示格式化数据
- 将格式化的数据发送到前端
因此，前端上的逻辑将最小化。因此，BFF有助于简化数据表示，并承担提供前端一个专注的接口的责任。
另一种简化后端-前端关系的好方法是在它们之间共享类型。了解如何使用Bit在解耦项目之间共享类型（或任何其他代码）：
如果你更喜欢观看：
BFF在电子商务示例中的作用是什么？
以下图表显示了每个微服务如何通过BFF与前端连接。
BFF的角色
正如我们已经探讨过的，BFF充当前端和微服务之间的简单接口。理想情况下，前端团队将负责管理BFF。
单个BFF专注于单个UI，仅限于该UI。因此，它将帮助我们保持前端简单，并通过其后端看到数据的统一视图。
这带来了下一个问题。我们可以为多个UI拥有多个BFF吗？我们将在本文的后面部分回答这个问题。请继续阅读。😊
这会增加延迟吗？
现在我们知道，BFF类似于客户端和其他外部API、服务等之间的代理服务器。如果请求必须通过另一个组件，它肯定会增加延迟。然而，与浏览器需要处理多个未针对前端优化的服务相比，BFF延迟是可以忽略的。
构建BFF允许你智能地对其他后端/微服务进行批量调用，并一次性返回数据，或通过转换和格式化数据返回更方便的表示。
这对于2G或3G网络上的移动客户端非常有用，因为建立连接可能需要几秒钟或更长时间。
何时在应用程序中使用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实现BFF - 你的自包含API应该在微服务层中。大多数开发人员会忘记这一点，并开始在BFF中实现服务级API。你应该记住，BFF是客户端和服务之间的翻译层。当从服务API返回数据时，其目的是将其转换为客户端应用程序指定的数据类型。
- 避免BFF逻辑重复 - 一个重要的要点是单个BFF应该满足特定的用户体验，而不是设备类型。例如，大多数情况下，所有移动设备（iOS、Android等）共享相同的用户体验。在这种情况下，为所有这些操作系统提供一个BFF就足够了。没有必要为iOS和Android分别提供一个独立的BFF。
- 避免过度依赖BFF - BFF仅仅是一个翻译层。是的，它也为应用程序提供了一定程度的安全性。但是，你不应该过度依赖它。你的API层和前端层应该照顾到所有的功能和安全方面，无论BFF是否存在。因为BFF应该填补一个空白，而不是为应用程序添加任何功能或服务。
- 为了在你的微服务中实现一个更可管理的前端后端（BFF）模式，一个好的做法是将每个视为组件，然后利用模块化、可重用和共享的方法来利用它们。为此，你可以再次使用Bit创建、版本、发布和共享每个组件作为单独的包 - 或者甚至使用Bit的变体为每个创建不同的配置。
总结
BFF模式不仅有助于开发，还能极大地改善用户体验。因此，在保持BFF专注于前端的同时，考虑数据优化和聚合是至关重要的。
此外，如果你以前没有使用BFF模式，现在是时候开始了。
以下是你可以用来实现BFF模式的一些工具：
让我知道你的经验和意见。 😃
从单体软件到可组合软件的转变
Bit的开源工具帮助25万+开发人员构建带有组件的应用程序。
将任何UI、功能或页面转换为可重用的组件 - 并在你的应用程序之间共享它。这样更容易协作和更快地构建。
译自：https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
评论(0)