大前端架构思考与选择

问题

“一云多端”成为趋势，终端类型越来越多。比如，现在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，为前端而存在的后端)