前端专题技术总结3

1、大前端架构思考与选择

问题

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

解决方法

• 针对“一云多端”，可以在BFF层做适配。可以考虑MVVM的模式，从服务器来的数据当做Model，在BFF中针对各种端，提供不同的ViewModel。如果数据变了，只要修改Model就可以了。如果要增加一种端，只要增加一个ViewModel就可以了。在这里集中修改，就可以解放各个终端的格式转化工作。
• “前后端分离”之后，各种端可以融合为一个“大前端”，跟后端对话的窗口就是BFF。对于后端来说，只要满足BFF的数据需求就可以了，剩下的事情，就让“大前端”内部自己解决。
• 服务端设计的API接口，面向通用服务，不需要面向UI。各种端的UI差异，由BFF层负责适配。这样的话，可以让后端更加专注于业务逻辑和数据服务，不需要操心各种端的差异。
• 整个开发流程太长，导致相互等待，造成浪费。针对这个问题，可以考虑在BFF层将开发流程分为两部分。“大前端”作为一个独立开发部门，领先后端一个版本发布周期。
  具体做法是，对于新业务，将Mock数据生成在BFF层，对于各种端来说，相当于后端服务已经好了，可以直接进行联调，不需要等待。这样就把前端对后端的数据依赖去除了，更加灵活。

特殊之处

Mock数据

• 以前的Mock数据由开发自己负责，要么直接代码写死，要么借助Charles等工具。现在，将Mock数据由测试统一负责，直接生成在BFF层。
• 以前开发要写自测代码，单元测试代码；测试设计出用例数据之后，一般通过流程工具，比如JIRA，要求开发自测。现在的模式是测试专职维护BFF上的Mock数据，将设计的用例转化为实际可用的Mock数据，开发测试用同一套标