BFF模式（Backends for Frontends pattern）-
https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends。
创建单独的后台服务用以提供给特定的前端或者接口。当你希望避免为多个接口定制单独的后台时，此模式非常有用。这个模式最开始由Sam Newman提出。
背景和问题
- 应用程序最初可能针对web、UI。一般来说后端服务是和前端并行开发的，它提供该前端所需的功能。随着应用程序用户群的增长，开发了必须与相同后端交互的移动应用程序。后端服务成为通用后端，同时满足桌面和移动接口的需求。
- 但是在屏幕大小、性能和显示限制方面，移动设备的功能与桌面浏览器有很大的不同。因此，对移动应用程序后端的需求不同于web、UI。
- 这些差异导致了后端需求的竞争。后端需要定期进行重大更改，以同时服务于web、UI和移动应用程序。通常，独立的接口团队负责每个前端，导致后端成为开发过程中的瓶颈。冲突的更新需求，以及保持服务在两个前端工作的需要，可能会导致在单个部署资源上花费大量精力。
- 当开发活动集中于后端服务时，可能会创建一个单独的团队来管理和维护后端。最终这会导致接口和后端开发团队之间的脱节，给后端团队带来负担，以平衡不同前端团队的需求。当一个接口团队需要对后端进行更改时，必须先与其他接口团队验证这些更改，然后才能将其集成到后端。
解决办法
- 为每个用户接口创建一个后端。微调每个后端的行为和性能，以最好地匹配前端环境的需求，而不必担心影响其他前端体验。
- 由于每个后端都特定于一个接口，因此可以针对该接口进行优化。因此，它将比试图满足所有接口需求的通用后端更小、更不复杂，并且可能更快。每个接口团队都有自主权来控制他们自己的后端，而不依赖于集中的后端开发团队。这使接口团队在语言选择、发布节奏、工作负载优先级和后端特性集成方面具有灵活性。
- 关于它更多的信息，可以访问：https://samnewman.io/patterns/architectural/bff/
问题和考虑
- 考虑由多少个后端要部署。
- 如果不同的接口(例如移动客户端)将发出相同的请求，请考虑是否有必要为每个接口实现一个后端，还是单个后端就足够了。
- 在实现此模式时，不同服务的代码复制极有可能发生。
- 以前端为中心的后端服务应该只包含特定于客户端的逻辑和行为。一般业务逻辑和其他全局特性应该在应用程序的其他地方进行管理。
- 考虑一下这种模式如何反映在开发团队的职责中。
- 考虑一下实现这个模式需要多长时间。当您继续支持现有的通用后端时，构建新后端的工作是否会带来技术债务?
什么时候使用
- 共享的或通用的后端服务必须用大量的开发开销来维护。
- 你需要针对特定客户端接口的需求优化后端。
- 对通用后端进行定制以适应多个接口。
- 某个编程语言更适合特定用户接口的后端，不是所有用户接口。
不适用
- 当接口发送相同或相似的请求给后台。
- 当时只有一个接口与后台交互时。
相关
- Gateway Aggregation pattern
- Gateway Offloading pattern
- Gateway Routing pattern
欢迎大家留言沟通
