BFFIS bff 前端


了解在实践中使用BFF模式的好处

BFFIS bff 前端

文章插图

想象一下,您需要使用微服务构建电子商务应用程序的场景 。您可以为客户,订单,产品,购物车等具有微服务 。微服务将暴露前端使用API 。
但是,通过微猎狼人返回到前端的数据可能不会根据前端需要表示它们的确切方式进行格式化或过滤 。
在这种情况下,前端需要自己拥有一些逻辑来重新格式化这些数据 。在前端具有此类逻辑将使用更多的浏览器资源 。
在这样的情况下,我们可以使用BFF来将一些这个前端逻辑转移到中间层 。中间层是BFF 。当前端请求某些数据时,它将调用BFF中的API 。
BFF将执行以下操作 。
  • 调用相关的微服务API并获得所需的数据
  • 根据前端表示格式化数据
  • 将格式化的数据发送到前端
结果,前端将存在最小的逻辑 。因此,BFF有助于简化数据表示,并占用为前端提供富裕的接口的责任 。
它如何适合电子商务榜样?下图显示了每个微服务如何通过BFF与前端连接 。
BFFIS bff 前端

文章插图

BFF的作用正如我们已经探索的那样,BFF充当前端和微服务之间的简单界面 。理想情况下,前端团队也将负责管理BFF 。
单个BFF专注于单个UI,仅限UI 。因此,它将有助于我们通过其后端保持始终简单地看到数据的统一视图 。
这带来了下一个问题 。我们可以为多个UI有多个BFF吗?我们将在本文的后一段中回答此问题 。继续阅读 。
这会增加延迟吗?现在我们知道,BFF类似于客户端和其他外部API,服务等之间的代理服务器 。如果请求必须通过另一个组件,它肯定会增加延迟 。但是,与浏览器的高资源使用相比,BFF延迟可以忽略不计,如果需要使用未针对前端优化的多个服务 。
构建BFF允许您智能地对其他后端/微服务进行批量调用并一次返回数据,或者通过转换和格式化数据来返回更方便地表示 。
这对于2G或3G网络上的移动客户端非常有用,其中可能需要几秒钟(或更多)以建立连接 。
何时为您的应用程序使用BFF与许多其他模式一样,使用应用程序中的BFF取决于您计划遵循的上下文和架构 。例如,如果您的应用程序是一个简单的单片应用程序,则不需要BFF 。它不会增加没有价值 。
但是,如果您的应用程序取决于微服务并消耗许多外部API和其他服务,最好使用BFF来简化数据流并向您的应用引入大量效率 。
此外,如果您的应用程序需要为特定前端接口开发优化的后端,或者您的客户端需要使用在后端中需要大量聚合的数据,BFF是合适的选项 。
提示:分布式设计需要不同类型的代码协作 。使用位(github)在可以在Repos共享并独立开发的各个组件上进行协作 。
保持存储库可扩展,可维护,始终同步 。


我们可以有多个bffs吗?我们当然可以!这是拥有BFF的全部点 。
传统方法(没有BFF的应用程序)将仅为所有客户端拥有一个API网关 。它将如下所示 。
BFFIS bff 前端

文章插图
> Source


但是,拥有BFF的目的是为您的客户提供连接的聚焦界面 。例如,移动UI的数据消耗可能与浏览器的数据消耗不同 。在这种情况下,为了更好的数据表示,可以使用两个BFF 。让我们来看看具有多个BFF的应用程序图 。


特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。