BFF一词来自Sam Newman的一篇博文《Pattern:Backends For Frontends》,指的是服务于前端的后端。提出这个概念的目的是为了解决什么问题呢?从大的方向来说,主要有以下两个方面:
那么当面业界的解决方案有哪些呢?
针对这样的场景,现在一般会引入 BFF 这一中间层,让前端应用直接和 BFF 通信,BFF 再和后端 API 进行通信,获取数据并且处理完以后返回给前端。这样就能比较好的满足前后端各自的需求。其实从本质上来说是前端面向页面场景和后端面向业务领域之间的矛盾,由 BFF 这层来解决。
业界针对BFF的解决方案抓哟主要有两种模式:
后端BFF模式指的是BFF由后端同学负责,这种模式目前最广泛的实践是基于GraphQL搭建的后端BFF方案,具体是:后端将展示字段封装成展示服务,通过GraphQL编排之后暴露给前端使用。
这种模式最大的特性和优势是,当展示字段已经存在的情况下,后端不需要关心前端差异性需求,按需查询的能力由GraphQL支持。这个特性可以很好地应对不同场景存在展示字段差异性这个问题,前端直接基于GraphQL按需查询数据即可,后端不需要变更。同时,借助GraphQL的编排和聚合查询能力,后端可以将逻辑分解在不同的展示服务中,因此在一定程度上能够化解BFF这层的复杂性。
但是基于这种模式,仍然存在几个问题:
这种模式的理念是,前端完全接手BFF的开发工作,实现数据查询的自给自足,大大减少了前后端的协作成本。但是这种模式也存在一些前提条件及弊端,比如较为完备的前端基础设施;前端不仅仅需要关心渲染、还需要了解业务逻辑等。
要实现一个BFF框架,不是一件容易的事情,往往会适得其反,一般需要根据业务实际出发,有以下一些建议: