大前端架构思考与选择 _前端架构

问题

“一云多端”成为趋势，终端类型越来越多。比如，现在PC Web网站的产品已经有了，现在想扩展App ，小程序... ...怎么办？一个直接能想到的方法就是在原来的基础上，为APP等增加API接口，如下图所示：

文章插图

这样做是可以的，然而一旦遇到修改，那么要同时修改几个端的代码，很麻烦，不是很完美。

“前后端分离”成为趋势。一开始的PC Web网站，大多是采用服务端渲染的前后端一体化的模式。随着技术的发展，前后端分离，前端渲染逐渐成为趋势。相应地，前端开发人员也从后端团队中独立出来。

【大前端架构思考与选择】现在兴起的APP ，小程序等，天生就是前后端分离的。前端， APP ，小程序等各自独立成专门的团队，当然可以满足这种趋势。相应地服务端需要为每一个前端部门提供服务，在实践中常常发现，重复的内容很多，有没有办法增加复用？或者说后端能否只对接一个“大前端”部门，剩下的“大前端”部门内部自己解决？

文章插图

服务端设计的API接口，面向通用服务，还是面向UI？各个端对数据的显示要求不同，给一个公共的API还是分别给不同的API？

比如，时间显示， PC端可能要求“2020-8-9”的格式，而APP端可能要求“2020/8/9”的格式，接口怎么给？
再比如，相同功能的一个接口， PC Web端需要20个字段，已经做好了。现在APP端因为屏幕小，只要10个字段就够了，是复用老的API ，让APP忍受垃圾信息，还是为APP额外新增一个接口？
前端和服务端人员可能会有不同意见，这就带来了冲突。大家都有一定的道理，怎么协调？

产品经理提出PRD-》UED设计交互稿-》UI设计界面-》后台设计API接口-》后台实现服务-》前后端联调... ..

架构从现状来看，前后端分离之后，服务端直接给各种端提供服务是很自然能够想到的一种方式。这种方式的优点是简单直接，缺点是不够灵活。因此，考虑在前端和后端之间插入一个中间层，作为前后端之间的桥梁，增加灵活性。
对于这个中间层的称呼，一种是“网关层或者接入层” ，这个可能会和后台现有的网关和接入层造成混淆。另一种叫法叫做BFF(Backend for Frontends ，为前端而存在的后端) ，这种称呼相对比较准确，不会带来混淆。

网关层或者接入层

文章插图

BFF(Backend for Frontends ，为前端而存在的后端)

文章插图

解决方法

针对“一云多端” ，可以在BFF层做适配。可以考虑MVVM的模式，从服务器来的数据当做Model ，在BFF中针对各种端，提供不同的ViewModel 。如果数据变了，只要修改Model就可以了。如果要增加一种端，只要增加一个ViewModel就可以了。在这里集中修改，就可以解放各个终端的格式转化工作。
“前后端分离”之后，各种端可以融合为一个“大前端” ，跟后端对话的窗口就是BFF 。对于后端来说，只要满足BFF的数据需求就可以了，剩下的事情，就让“大前端”内部自己解决。