关于BFF层的思考

背景:

1.前端需要处理的业务逻辑越来越多,各种特殊处理,代码越来越dirty

2.服务端设计的API接口,面向通用服务,还是面向UI?后端字段格式多种多样,有的时候想要改个字段非常难

  • 「你自己请求 2 个接口再组装不就行了?」 - 后端同学追求服务下沉和解耦。

  • 「少一次 HTTP 啊,加一个接口有那么难么?」 - 前端同学离用户最近,需要考虑用户体验灵活性。

3.联调耗费大量时间来沟通和扯皮

4.为多端服务使用相同API提供可能性

服务端需要为每种终端(PC、h5、APP、小程序)提供服务,有很多接口实际是重复的,有没有办法增加API复用,在BFF层提供定制服务?

BFF概念

BFF,即 Backends For Frontends (服务于前端的后端),也就是服务端设计 API 时会考虑前端的使用,并在服务端直接进行业务逻辑的处理。

Sam Newman曾在他的博客中首次提出了BFF的概念,并介绍了BFF(Pattern: Backends For Frontends)

这一层之前没有明确提出来前,后端有很多与UI有关的逻辑和数据处理。

加入了BFF的前后端架构中,最大的区别就是前端不再直接访问后端微服务,而是通过 BFF 层进行访问。
这一层属于典型的无状态IO密集型模块,非常适合吞吐能力巨大的 node.js 开发,用 java 开发也不会带来什么额外的性能优势;这些数据处理都应该放在BFF层,保持了前端和后端代码的纯洁。

看到一段总结的比较好:

  • 服务自治,谁使用谁开发,自己吃自己的狗粮

  • 服务自治减少了沟通成本,带来了灵活和高效

可能遇到的问题

1.研发成本增加,对开发者能力要求更高

2.nodejs服务能力有待验证

参考阅读:
BFF概念提出:https://samnewman.io/patterns/architectural/bff/
微服务下使用GraphQL构建BFF:https://zhuanlan.zhihu.com/p/35108457
蚂蚁财富BFF实践:https://os.alipayobjects.com/rmsportal/WtUmBLJSmqtDHkvJzuzM.pdf