问题
“一云多端”成为趋势,终端类型越来越多。比如,现在PC Web网站的产品已经有了,现在想扩展APP,小程序... ...怎么办?一个直接能想到的方法就是在原来的基础上,为APP等增加API接口,如下图所示:
这样做是可以的,然而一旦遇到修改,那么要同时修改几个端的代码,很麻烦,不是很完美。
“前后端分离”成为趋势。一开始的PC Web网站,大多是采用服务端渲染的前后端一体化的模式。随着技术的发展,前后端分离,前端渲染逐渐成为趋势。相应地,前端开发人员也从后端团队中独立出来。
最近兴起的APP,小程序等,天生就是前后端分离的。
前端,APP,小程序等各自独立成专门的团队,当然可以满足这种趋势。
相应地服务端需要为每一个前端部门提供服务,在实践中常常发现,重复的内容很多,有没有办法增加复用?或者说后端能否只对接一个“大前端”部门,剩下的“大前端”部门内部自己解决?服务端设计的API接口,面向通用服务,还是面向UI?各个端对数据的显示要求不同,给一个公共的API还是分别给不同的API?
比如,时间显示,PC端可能要求“2018-6-11”的格式,而APP端可能要求“2018/6/11”的格式,接口怎么给?
再比如,相同功能的一个接口,PC Web端需要20个字段,已经做好了。现在APP端因为屏幕小,只要10个字段就够了,是复用老的API,让APP忍受垃圾信息,还是为APP额外新增一个接口?
前端和服务端人员可能会有不同意见,这就带来了冲突。大家都有一定的道理,怎么协调?
产品经理提出PRD-》UED设计交互稿-》UI设计界面-》后台设计API接口-》后台实现服务-》前后端联调... ...
以上是一般的开发流程,整个过程还是比较长的。前端在开发完静态页面之后,常常需要等后台服务开发好了,才能联调,这里往往有等待时间的浪费。等后台服务好了,往往提测时间也临近了,气氛很紧张。整个开发体验,往往就是“一半是海水,一半是火焰”。有没有办法缩短这个流程,并且能够让前端不依赖后台服务的完成,独自完成开发?
架构
从现状来看,前后端分离之后,服务端直接给各种端提供服务是很自然能够想到的一种方式。这种方式的优点是简单直接,缺点是不够灵活。因此,考虑在前端和后端之间插入一个中间层,作为前后端之间的桥梁,增加灵活性。
对于这个中间层的称呼,一种是“网关层或者接入层”,这个可能会和后台现有的网关和接入层造成混淆。另一种叫法叫做BFF(Backend for Frontends,为前端而存在的后端),这种称呼相对比较准确,不会带来混淆。
网关层或者接入层
BFF(Backend for Frontends,为前端而存在的后端)