BFF is a web architecture, the full name is Backends For Frontends, which is the backend serving the frontend. The term comes from an article by Sam Newman: Pattern: Backends For Frontends . BFF generally refers to adding an intermediate layer between the front end and the back end. Why add a BFF layer between the front end and the back end?
Computer scientist David Wheeler once said: All problems in computer science can be solved by another level of indirection.All problems in computer science can be solved by adding a layer. Therefore, the scene that needs to use BFF must be that the ordinary front-end and back-end development models have encountered some problems. For example, Sam Newman's article describes the scenario where BFF solves multiple display terminals.
Multi-terminal display problem
When the system was first developed, only the design of the PC web page was considered, and the server-side API was for the PC web page. But later, with the rise of the mobile Internet, the mobile terminal became popular, and decided to develop the mobile app on the basis of the original server and reuse the previous API, but the original API was designed for the PC terminal and did not meet the needs of the mobile terminal.
- The requirements of the PC terminal are not necessarily the same as those of the mobile terminal, and the existing interface cannot meet all the new requirements of the mobile terminal.
- The performance of the PC terminal is strong, and it can request multiple interfaces concurrently or perform some complex data processing, but the performance of the mobile terminal is low. If the same multiple interfaces are used and the data is assembled by the front end, the page display may be delayed and stuck. .
- The screen on the PC side is larger, and the display content is more and comprehensive. However, the screen of the mobile terminal is small and the display content is less. Moreover, it is not easy to obtain some data, and the backend needs to call many services. If the mobile terminal reuses the PC terminal interface, some useless data will be acquired and transmitted, which not only consumes server resources, but also wastes network bandwidth.
Moreover, with the development of technology and the needs of users, there are more and more different display terminals. Not only will Android and IOS terminals be distinguished on mobile phones, but there will also be tablet PC terminals, mobile web pages, PC web pages, and PC web pages. APP end and so on. The page designs of these terminals are different, and the requirements for data are also different. Assuming we reuse the same server and API interface, if there is a scene that does not meet the requirements, add the interface and add fields, then with the development and iteration of these different clients, the server will become large, bloated, and inefficient. Moreover, the same interface is provided for too many front-end calls, involving too much logic, and the complexity is getting higher and higher.
Therefore, a better way is to decouple the display from the server. The server is only responsible for providing data, and a dedicated display terminal is responsible for the front-end display business. The display side here is the BFF layer.
Differences in display modes for different business scenarios
In some businesses, there is only one type of client, but in different scenarios, the displayed modes are different. For example, in Meituan’s BFF practice , the display modules of group buying shelves in different industries are different. They are two sets of independently defined product logic, and they will be iterated separately.
In this business scenario, although it is the same client, the business is different, and the required data format and type are also different, so it encounters an interface problem similar to the above multi-terminal display.
short life cycle needs
Another situation is the short life cycle requirements encountered by the Xianyu team . In common business scenarios, the server is normally and stably developed iteratively. But occasionally there will be some special operational activities, which are short-lived and may last only a few days.
If only for the activities of these few days, it is costly and inefficient to open a new API, joint debugging, or even modify the logic of the original server every time. If a layer of BFF is added so that the front-end can directly obtain data, then development and joint debugging will become much easier.
business integration needs
在某些情形下，业务后端和需求比较复杂，例如这篇文章涉及到的场景，有一个Moments App,包含了像用户管理，关系管理，信息，头像，点赞等多种多种后端微服务。这些服务在前端展示的逻辑耦合性较强。比如有些需要串行处理，例如得到服务1的结果才可以调用服务2；有些则可以并行处理。而数据合并和整理的逻辑额较为复杂。
图片来源：跨平台架构：如何设计 BFF 架构系统？
网易云音乐也使用BFF进行微服务的调度以及数据的组装和适配。
这时候可以设立一个BFF层，作为一个数据整合服务，将调用不同微服务接口，与数据处理的复杂逻辑都在BFF端中实现，降低了前端的复杂度，也提高了响应效率。
处理部分展示相关的业务
在使用了BFF之后，部分页面展示相关的业务逻辑可以抽象出来，交由BFF端处理。
例如数据导出Excel下载服务，输入导入Excel上传服务。BFF层可以接收用导入的Excel，解析并处理表格数据，然后提供给服务端。在导出时，也可以调用服务端API获取数据，由BFF端整合提供给前端下载。在这种情形下，服务端只需要提供一个展示接口，就可以满足页面展示和导出两种不同格式的展示需求。导入也是同理。而且假设表格与页面展示要求的数据格式不同，例如导入时部分字段值需要作转换，那么也可以由BFF端处理这种差异。
BFF的类型
BFF本身仅仅是一个概念，实现方式有多种，在实际中我们要根据不同的场景选取不同的方案。按照大类分，主要有单一BFF和多端BFF。
单一BFF
单一的BFF主要对接服务端，根据展示服务的需求组装数据提供给每个端或者每种业务进行展示。
很多单一BFF都会用到GraphGL，他是由Facebook开发的数据查询工具。通过该工具，可以将不稳定的数据组装部分从稳定的业务数据逻辑中剥离，使数据控制逻辑前移，开发模式由“下发数据”转变成“取数据”的过程。
例如美团，闲鱼，网易云音乐等的BFF，都提供了按需查询能力，一个BFF对接多种客户端或者多种业务的需求。下图是美团使用的BFF架构设计。
图片来源：GraphQL及元数据驱动架构在后端BFF中的实践
多端BFF
多端BFF是指每种业务或者每种客户端采用自己独立的BFF层，这样每种客户端的服务更加灵活，不同的BFF端对于展示服务解耦性更高。
前端BFF与后端BFF
从技术上分，BFF又可以分为前端BFF和后端BFF。即BFF层由前端团队主导或者后端团队主导。前端团队的BFF一般使用Node.js，后端团队则会使用Java或者其他服务端语言。
如果使用前端BFF，可以实现谁使用谁开发，一定程序生避免了前后端实现的上不必要的沟通成本。但需要前端团队有一服务端开发经验，对前端团队的技术建设有较高需求。但是前端也能更深入的接触业务逻辑，对于重展示的业务需求有一定优势。例如淘宝的实践：大淘宝技术行业FaaS化实战经验分享。
传统接口与按需查询
传统接口模式即正常开发接口，固定入参和返回数据格式，供前端调用。按需查询模式即前端调用接口时指定需要哪些数据，前端自主进行按需查询。GraphQL即是使用按需查询的模式。
BFF的其他特点
与ServerLess集成
使用前端BFF时，前端开发可能缺乏运维经验，而且在高可用，并发性等问题上可能会遇到挑战。如果结合Serverless实现自动扩容，弹性伸缩等功能，可以解决一些BFF的问题。
阿里云的云原生团队介绍了这一方法：基于函数计算的 BFF 架构（图片来源）
BFF与网关
网关可以提供路由，认证，监控，日志等服务。网关可以与BFF集成在一起，也可以作为独立的一层来实现。如果业务复杂，还可以在不同的BFF上层配置不同的网关。
这篇文章介绍了在不同场景下，BFF层与网关的应用。 微服务架构：BFF和网关是如何演化出来的？（图片来源）
BFF的优势
通过上面的的各种问题和场景，相信我们已经知道了BFF可以解决很多场景的问题，这里总结一下BFF的优势：
- 服务端对数据展示服务进行解耦，展示服务由独立的BFF端提供，服务端可以聚焦于业务处理。
- 多端展示或者多业务展示时，对与数据获取有更好的灵活性，避免数据冗余造成消耗服务端资源。
- 对于复杂的前端展示，将数据获取和组装的负责逻辑在BFF端执行，降低前端处理的复杂度，提高前端页面响应效率。
- 部分展示业务，可以抽象出来利用BFF实现，对于服务端实现接口复用。
- 降低多端业务的耦合性，避免不同端业务开发互相影响。
- 其他优势，包括数据缓存，接口安全校验等。
参考
- Pattern: Backends For Frontends
samnewman.io/patterns/ar… - GraphQL及元数据驱动架构在后端BFF中的实践 美团技术团队
mp.weixin.qq.com/s/mhM9tfWBl… - 高效研发-闲鱼在数据聚合上的探索与实践 闲鱼技术
mp.weixin.qq.com/s/9P_16cNEF… - 跨平台架构：如何设计 BFF 架构系统？
www.jianshu.com/p/bfc652bac… - 什么是 GraphQL？ 知乎
www.zhihu.com/question/26… - DDD Series Article 10: BFF Architecture
www.cnblogs.com/arrowolf/ar… - BFF Architecture Based on Function Computing Alibaba Cloud Cloud Native
juejin.cn/post/684490… - Microservice architecture: How did BFF and gateways evolve?
juejin.cn/post/684490… - GraphQL-based cloud music BFF construction practice Netease cloud music technology team
juejin.cn/post/718201… - Big Taobao technology industry FaaS practical experience sharing
juejin.cn/post/714352…