ps：服务提供给前端的数据可能不会按照前端需要的方式进行编排或过滤。
这种情况下，前端需要一些逻辑来重新处理这些数据，同时在用户端使用这样的逻辑会占用更多的浏览器资源。
在这样的情况下，我们可以使用 BFF 将一些前端逻辑转移到中间层，中间层就是 BFF。当前端请求一些数据时，它将调用 BFF 中的 API。
BFF 将执行以下操作：
- 调用相关的微服务 API 并获取所需数据
- 根据前端展现来处理数据
- 将格式化后的数据发送到前端
因此，前端将有更少的逻辑，BFF 有助于简化数据展示，并为前端提供一个目的明确的接口。
场景：需要去请求多个后台，有一些数据展示需要多个接口的数据汇集后才能展示，在前端内部就需要做一些同步，确保多个接口的数据都回来后才展示的promise逻辑。
这会增加延迟吗？
现在我们知道 BFF 类似于客户端和其他外部 API、服务等之间的代理服务器。如果请求必须通过另一个组件，它肯定会增加延迟。但是，如果浏览器需要处理多个未针对前端优化的服务，那么与浏览器的高资源使用率相比，BFF 延迟可以忽略不计。
构建 BFF 允许你智能地对其他后端 / 微服务进行批处理调用，并一次返回所有数据，或者通过转换和格式化数据来返回更方便的展现形式
BFF（Backend for Frontend）是一种设计模式，用于设计针对每个前端客户端的特定需求而定制的多个后端服务。这种方法有助于减少使用单一后端服务多个前端的复杂性和扩展问题。
例如，同一应用程序的移动版本和 Web 版本可以具有不同的数据格式、性能要求和身份验证方法。但是，使用传统的整体后端向特定前端客户提供这些特定需求是具有挑战性的。通过 BFF 模式，开发人员可以通过为每个前端提供自己的定制后端来满足特定需求来克服这种情况。
前端后端 (BFF) 模式是一种设计模式，涉及为每个前端客户端创建单独的后端服务。它在客户端和 API 之间创建一个数据转换层，以防止过度获取和获取不足的数据
在上图中，您可以看到针对 Web 和移动设备实现的 BFF 的两个示例。BFF模式的请求和响应周期解释如下：
- 客户端向 BFF 发送请求。
- BFF 向内部微服务发送请求并收集所需的数据来满足客户端请求。
- BFF 汇总收集到的数据。
- BFF 将所需数据返回给客户端以供其使用。
客户端直接与 BFF 交互，以确保仅发送必要的数据来填充前端 - 不多或少。此外，BFF 模式在不同的前端和后端团队之间创建了关注点分离，并允许每个团队独立工作并优化其应用程序的特定领域。
BFF 优势：
最好的朋友的好处
- BFF 模式使企业能够快速扩展并引入具有不同需求的新客户，而无需更改其后端。BFF 可以通过仅提供所需的数据来满足每个客户端的需求，而不会过度获取或获取不足。
- BFF 不在客户端之间共享，这有助于平衡负载并防止所有客户端在单个入口点过载。
- 通过 BFF 模式，前端和后端团队不再需要相互依赖。他们可以独立工作并利用 BFF 集成两个组件，从而实现更高效的开发流程。
- BFF 模式通过提供对数据暴露的更好控制来帮助降低潜在数据泄露和其他安全漏洞的风险。
总之，BFF 是一种重要的架构模式，提供前端客户端和后端服务之间的无缝通信通道。BFF 模式允许为不同的前端客户端开发不同的后端服务，从而显着增强用户体验、加速软件交付并优化性能。
然而，实现 BFF 模式带来了一些实际挑战，例如创建和管理多个后端服务，这会增加整个系统的复杂性。因此，将后端服务设计得尽可能模块化和灵活非常重要。
您可以使用像Bit这样的工具，使用独立的组件来实现 BFF 模式，以避免重复并大大降低系统的复杂性。此外，API 网关服务、服务网格、监控和日志记录工具提供了支持 BFF 架构的高级特性和功能。这些工具可确保微服务之间的无缝通信、监控和记录系统错误并提高系统性能。
总的来说，BFF 模式已被证明是构建可扩展、灵活且高效的应用程序的高效解决方案。它的采用可以显着提高软件系统的性能。
实践中应遵循的最佳实践
到目前为止我们所看到的令人惊叹！然而，最好的朋友真的是万无一失的吗？
答案是不！与所有其他技术或模式一样，即使是最好的朋友也有陷阱。为了避免这些，我们必须遵循最佳实践。
- 避免使用独立的全包式 API 来实现 BFF — 您的独立 API 应该位于微服务层。大多数开发人员忘记了这一点，并开始在 BFF 中实现服务级 API。您应该记住，BFF 是客户端和服务之间的转换层。当数据从服务 API 返回时，其目的是将其转换为客户端应用程序指定的数据类型。
- 避免 BFF 逻辑重复— 需要注意的重要一点是，单个 BFF 应迎合特定的用户体验，而不是设备类型。例如，大多数时候，所有移动设备（iOS、Android 等）都共享相同的用户体验。在这种情况下，所有这些操作系统的一个 BFF 就足够了。无需为 iOS 和 Android 分别设置一个 BFF。
- 避免过度依赖 BFF ——BFF 只是一个转换层。是的，它也为应用程序提供了一定程度的安全性。但是，您不应该过度依赖它。无论 BFF 是否存在，您的 API 层和前端层都应该负责所有功能和安全方面。因为 BFF 应该填补空白，而不是向应用程序添加任何功能或服务。
- 要为微服务实现更易于管理的后端到前端 (BFF) 模式，一个好的做法是将每个组件视为组件，然后为它们利用模块化、可重用和可共享的方法。 为此，您可以再次使用Bit作为单独的包来创建、版本化、发布和共享每个组件，甚至使用 Bit 的变体为每个组件创建不同的配置。
拥有 BFF 的优势
拥有 BFF 的一些优势如下：
- 关注点分离——前端需求将与后端关注点分离。这样更容易维护。
- 更容易维护和修改 API — 客户端应用程序对 API 结构的了解更少，这将使其更能适应这些 API 中的更改。
- 前端更好的错误处理——大多数时候，服务器错误对于前端用户来说毫无意义。BFF 可以映射出需要向用户显示的错误，而不是直接返回服务器发送的错误。这将改善用户体验。
- 多种设备类型可以并行调用后端——当浏览器向浏览器 BFF 发出请求时，移动设备也可以执行相同的操作。它将有助于更快地获得服务的响应。
- 更好的安全性——可以隐藏某些敏感信息，并且在向前端发送响应时可以省略前端不必要的数据。这种抽象将使攻击者更难瞄准应用程序。
- 组件的共享团队所有权——应用程序的不同部分可以很容易地由不同的团队处理。前端团队可以享有其客户端应用程序及其底层资源消耗层的所有权；导致高发展速度。下图显示了此类团队与最好的朋友分离的示例。
何时为您的应用程序使用 BFF
与许多其他模式一样，在应用程序中使用 BFF 取决于上下文和您计划遵循的架构。例如，如果您的应用程序是一个简单的整体应用程序，则不需要 BFF。它几乎不会增加任何价值。
但是，如果您的应用程序依赖于微服务并消耗许多外部 API 和其他服务，那么最好使用 BFF 来简化数据流并为您的应用程序引入大量效率。
此外，如果您的应用程序需要为特定前端接口开发优化的后端，或者您的客户端需要使用需要在后端进行大量聚合的数据，那么 BFF 是一个合适的选择。
BFF承担什么职责？
1、聚合：通过聚合后端多个接口的数据为前端提供所需要的完整数据。
2、裁减：过滤掉对于前端应用无用的数据。比如，去掉一些前端用不到的字段。
我们要时刻不忘遵守最少数据原则，客户端不需要的数据不要提供。
3、适配：根据端的不同提供端特有的数据。如，根据移动端系统或应用的差别，生成不同的分享或跳转链接。
4、验权：负责前端身份与权限认证，会话状态保持等。
5、安全：提供应用层安全层，防止非法请求，保证数据安全。如，用户身份认证，防止CSRF攻击等。
6、解耦：关注点分离（separation of concerns），BFF关注前端用户体验，后端API关注业务领域模型。不应当包含特定或核心的业务逻辑，不应当保存核心业务数据。
7、复用：有助于避免重复开发带来的工作量，也可以节约运维成本。BFF一个重要作用就是聚合不同前端应用的重复代码。当你发现相同业务的不同前端应用，通过API获取到数据后请求多个接口，或转换或过滤了一些响应数据，或都进行了相同的基于结果数据的进一步计算，此时，你需要考虑把这些代码迁移到BFF。
8、控制：BFF应当有能力根据前端应用的性质不同，控制哪些数据应当或不应该提供给哪个应用。
9、统一：BFF可以承担后端到前端数据传输过程中协议不一致，统一协议的角色。如，有的是HTTP[S]，有的是RPC。
10、提效：可以避免一个业务后台对接多个前端应用的困境，也可以避免一个前端应用需要对接多个业务后台的麻烦。
11、分流：可以用于分散用户端的并发请求。
BFF如何划分？
一种前端应用应当对接一个BFF。一个BFF可以对接多个前端应用，取决于前端应用需求的相似度，如，相同业务不同平台（Android、iOS）的App。划分的基本原则是UX的差异。
一个前端应用尽量对接一个BFF。
缺点有哪些？
1、由于在调用链路上又增加了一层，所以，会有网络延迟上的增加。
2、会增加微服务应用的数量，增加运维的难度。
