信息
后端的前端，还是前端的后端？
BFF 是什么？
BFF(Backend For Frontend) 的核心思想是：为每个前端界面或平台创建一个专属的轻量级后端服务，该服务负责：
- 聚合来自多个微服务的数据；
- 对数据进行裁剪、转换、格式化，以适配特定前端的需求；
- 处理与 UI 逻辑紧密相关的业务逻辑（如页面组装、权限控制等）；
- 避免前端直接调用多个后端微服务。
比如有以下几个场景：
- 你有一个大屏的项目，需要在页面展示时获取很多图表的数据。此时 API 端已经有数据，但是很零散，他们也没有时间来做数据整合
- API 端已经有数据接口，但是
WEB和移动端的展示逻辑不同，而且可能有不同的数据需求
如果要在现有服务端直接进行更改，可能会有很多的改动。在前端变化频繁的时候，后端也需要频繁的进行改动。
这时候就可以用到 BFF 了，它可以为每个端做不同的事，将一些数据整个的事放到指定的服务中。
在微服务架构中，后端会被分为多个服务，不同的数据会在不同的服务中存在。BFF 也可以看做是一个独立的微服务。
为什么需要 BFF
- 有时候一个接口会返回过多或者过少的数据，无法满足前端的需要。前端可能需要调用多个接口来组合，会增加前端的复杂度。
- 可以提升一些性能: 将之前多个请求降低为单个请求，并且可以在 BFF 中将之前使用 HTTP 请求改为使用更加快速的 RPC，并且可以在 BFF 层裁剪不需要的数据
提醒
RPC (Remote Procedure Call) 远程过程调用是一种通信协议，允许程序在不同计算机上执行代码，就像调用本地函数一样，隐藏了底层网络通信细节，广泛用于构建微服务和分布式系统，实现高效、透明的远程服务调用。它通过客户端-服务器模式工作，客户端发起调用，服务器响应，通常比HTTP更适合内部服务间的高性能通信
- 多端返回不同的数据: WEB 端可能需要比较完整的数据，移动端需要更加精简的数据。
- 降低对服务器的压力: 可以在 BFF 层设置缓存(如： Redis)，在有缓存时直接访问缓存
- 纯后端和前端进行解耦: 服务端可以不太关注前端需要的数据，数据可以在 BFF 中进行裁剪组合
可能出现的问题
- 增加复杂度: 只要增加一层肯定会增加复杂度，增加运维压力
- 责任归属问题: BFF 到底归属于前端团队还是后端团队？这部分的责任归属如何分配？
最佳实践：将 BFF 视为“前端的一部分”，由前端或全栈团队维护；保持其轻量、无状态、聚焦 UI 数据组装。
我实际遇到的 BFF 层的应用
- 小程序H5上传文件的 URL 获取
- 小程序中使用 H5上传文件，上传后获取文件的 URL 并且在小程序中展示
- 小程序|H5 城市数据的获取
- 中国城市的经纬度和编号获取。直接放到前端后，打包体积会变大。放到 BFF 层中进行获取。结合 Redis 缓存，打包体积减小并且访问速度和使用静态文件也没有很大的差距。
- Excel数据转换和文件导出
- 获取拼音首字母
- 和
第2条一样，减少前端的打包体积。
- 使用 puppeteer 将 HTML 转为 image 或 PDF
- 有将指定的页面转换为
图片或者PDF的需求，使用 puppeteer 很方便，并且可以给不同的几个项目提供此能力。
- 经纬度转换为物理地址
- 这个有第三方的 API，可以在 BFF 层中进行获取。因为它用到了第三方提供的 SECRET 和 KEY（放到前端可能会被盗刷），并且后端不需要此数据，所以都放到 BFF 层中进行获取。