BFF架构到底是什么?
概念
BFF,Backends For Frontends(服务于前端的后端),Sam Newman曾在他的博客中写了一篇相关文章Pattern: Backends For Frontends,在文章中Sam Newman详细地说明了BFF。
BFF就是服务器设计API时会考虑到不同设备需求,即为不同设备提供不同API接口,虽然它们可能实现相同功能,但因不同设备的特殊性,它们对服务端的API访问也各有其特点,需区别处理。因此出现了类似下图的
设计方式
图一
图二
客户端都不是直接访问服务器的公共接口,而是调用BFF层提供的接口,BFF层再调用基层的公共服务,不同的客户端拥有不同BFF层,它们定制客户端需要的API。图一、图二不同在于是否需要为相似的设备人,如IOS和android分别提供一个BFF,这需根据现实情况决定。
BFF V.S 多端公用、单一的API
满足不同客户端特殊交互引起的对新接口的要求
所以一开始就会针对相应设备设计好对应接口。若使用单一、通用API,而一开始并没有考虑到特殊需求,则有新请求需要出现时,可能出现:
- 若添加新接口,易造成接口不稳定
- 若考虑在原有接口上修改,可能产生一些耦合,破坏单一职责
案例
因为移动APP的屏幕限制,在某个列表页,我们只需展示一些关键信息,但由于调用的是服务端提供统一的API,服务端在设计时只考虑到web端,就返回了所有字段,但这些对移动端都无用。
优化性能时处理这样的问题,服务器端就需新增接口或通过引入相关耦合来解决。而使用BFF,很大程度能避免这类问题。
当由于某客户端需调用多个不同服务端接口,来实现某功能
可直接在对应BFF层编写相应API,而不影响基层公共服务,且客户端不用直接向多个后台发起调用,可优化性能。
BFF带来便利好处同时,也会引起一些问题:代码重复,加大开发工作量等。
所以在使用时需要结合现实情况仔细斟酌,符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景如下:
文章转载自公众号: JavaEdge