迪卡侬采用后端为前端 (BFF) 模式来增强 FE 团队的能力

迪卡侬建立了后端为前端 (BFF) 架构模式作为全公司范围的建议，并为其在工程团队中的采用提供了指南. 系列共四部分 介绍该模式并探讨其优点和潜在缺陷。 该公司还分享了使用 BFF 模式的替代方案并审查了架构注意事项.

迪卡侬是一家全球零售公司，拥有大型技术平台，将面向客户的电子商务平台与许多后台系统相结合。 由于有许多 Web 和移动前端应用程序，该公司需要帮助来支持其基于微服务的后端架构之上的不同用户体验的需求.

为了应对这些挑战，该公司推出了 前端的后端 (BFF) 模式，前端团队拥有并维护后端中间件服务，处理特定于支持其需求的编排和聚合。 这个新的抽象层可以更好地分离关注点并提高灵活性，同时减少系统组件之间的耦合.

前端模式的后端（来源: 迪卡侬数字博客)

BFF层可以容纳很多考虑因素, 包括数据操作/适应（API 数据，还有图像大小调整）、协议灵活性（WebSockets、GraphQL 等）、安全性（身份验证）以及对 服务器端渲染（SSR). 引入 BFF 可以让 FE 团队避免将数据获取、非规范化和聚合逻辑推送到 FE 应用程序中，从而降低了以下风险： 意大利面条代码 前端、代码和数据的网络使用情况、JavaScript 包大小以及浏览器中使用的计算资源.

BFF 模式并非没有挑战, 迪卡侬工程师制定了策略，以确保新层不会对平台的整体质量产生负面影响。 可以说，最大的风险来自于 BFF 之间不一致地复制业务逻辑，或者实现应在调用堆栈的较低层进行管理的业务逻辑。 迪卡侬呼吁成立一个架构委员会，以便定期讨论此类问题并使用 美国存托凭证 捕获任何结果 架构决策（AD).

容错和优雅降级（来源: 迪卡侬数字博客)

第二个需要注意的主要领域是容错，以确保 BFF 服务优雅地处理错误，并避免在不稳定的情况下压垮下游服务。 团队推广 断路器 和 舱壁 响应和隔离下游服务故障的模式。 如果发生故障，可能是陈旧的缓存数据，或者没有数据返回到前端应用程序，从而提供了优雅地降低用户体验的方法.

该系列的最后一部分 讨论 BFF 的替代方案，包括 无线部署（OTA), 哈特奥阿斯 和 哈尔, 和 服务器驱动的 UI (SDUI), 各自的优缺点以及不同类型有限元应用和组织规模的适合程度.

InfoQ 接受采访 拉斐尔·塔哈尔, 迪卡侬的一名工程师，讲述该公司使用 BFF 模式的经验.

InfoQ：您能大致总结一下迪卡侬在 BFF 模式方面的经验吗？ 在整个组织中推出 BFF 最具挑战性的元素/方面是什么?

拉斐尔·塔哈尔:

最困难的限制是建立一个标准，考虑到整个组织（数千个项目）中广泛的功能和技术用例).

• 一些由内部用户使用，另一些由客户使用
• 有些体验是在浏览器上消费的，另一些则是在移动或连接设备上消费的
• 技术组合的复杂性是可变的（技术雷达包括跨越 4 种以上语言的约 10 个框架）)
• 团队拓扑的差异（人员配置和硬技能)

最好的朋友不是灵丹妙药，因此实用主义是必须具备的，并使我们能够构建准确的决策树，但这并不容易.

InfoQ：许多组织采用 GraphQL 进行编排/聚合。 你能解释一下为什么你省略它作为 BFF 的替代品吗?

塔哈尔:

对我来说，GraphQL 更像是一种“查询语言 - 协议”，而不是一种架构模式本身。 它以头盔的形式出现，超越了现有服务并简化了相关数据的挑选。 所以，这是对 BFF 模式的一个很好的补充，但我不会说这两个概念是相互竞争的.

BFF 的重点是让前端团队拥有为其应用程序提供服务的 API，而 GraphQL 更多的是关于优化负载、端点和流量往返。 因此，BFF 和 GraphQL 相关但并不相互排斥.

另一方面，GraphQL Federation 可能是 BFF 的重要替代方案，但实现这种架构并非易事，尤其是在大型组织中.

InfoQ：微前端架构（MFA）是业界另一个流行的想法。 迪卡侬是否正在考虑采用它?

塔哈尔:

迪卡侬多年来一直在使用构建和运行时 MFA。 例如，使用 Web 组件可以从 Web 标准的纯度和稳定性中受益，但一些限制阻碍了全球采用。 因此，其他技术被用来弥补这一差距（例如., 单水疗中心-基于框架).