前后端协作的思考

软件架构分分合合，分层式架构的优势已为业界公认，但是分层带来的人员和工作之“分”也为“可工作的软件”之合带来了挑战。
在实际工作中，服务端接口不能满足界面的需求时，要前端调用发现问题反馈给服务端，然后服务端修改接口定义和业务逻辑，重新部署，前端再重新调用. “等接口，改接口、调接口”似乎成了前端开发工作中的“新常态”，这种前后端工作的串行化是项目工期经常延后的重要原因。
业界同仁有见及此，提出了增加一个中间层（即控制器接口层）的办法，一般的，控制器（controller）直接接收来自客户端（前端的请求），但因为控制器本身是后端提供的一种实现，而控制器接口层（为简略起见，后文接口文档和控制器接口层后文都简称为协议层）本身可视为前后端的一种协议和标准，可以让前后端并行开发，。前后端协作模型就变成这样：

这里我直接借用了yapi的图示，但图中的yapi只是支持协议层的一种工具，这里也可替换为mock-easy, RAP等其它工具。图中的DEV为后端同事，FE（frontend）为前端同事.其基本工作流程是，双方首先商定好接口格式（以yapi为例就是后端同学在yapi上写出接口文档），然后后端开发接口的实现，前端参照文档开始接口的调用。因为大多数协议层工具也提供了mockServer的功能（可视为协议层的默认实现，而后端同事的服务可视为协议层的业务实现），所以前端同事可以直接调用mockServer提供的接口。在前后端都完成开发后，前端转而使用后端提供的协议层的业务实现。这种转换类似java中的延迟绑定，在js中则是高阶函数，通常通过客户端请求的代理来完成这种转换。下面我分步叙述以上步骤。

0 选择提供协议层支持的工具, 这里我们使用yapi(https://hellosean1025.github.io/yapi/documents/index.html),选择内网部署,否则其无法访问内网的swagger文档进行接口的实时更新(意味着部署在外网则只能通过json文件更新接口).

1 完善协议层及默认实现
后端同事可以选择两种方式来部署接口文档，一种是通过yapi的编辑页面手动完成接口的编写，另一种是在代码中通过swagger撰写接口的api说明，然后通过yapi提供的同步导入工具将接口文档导致到yapi中并使用其自动智能更新的功能。前者的编辑方式大家都很熟悉了，后者在每个项目的设置菜单中可提供swagger(https://www.cnblogs.com/HackerBlog/p/8310123.html)的文档地址完成自动导入和自动同步。

 

 

在前端项目中，通用的服务器接口响应数据生成工具多使用mockjs(https://github.com/nuysoft/Mock/wiki/Getting-Started), 该工具可根据模板语法和规则生成随机响应内容，配合express等node服务器即可完成一个简单的mockServer.然而我认为既然接口为后端所提供，则mockServer似乎也应该由后端提供。像大多数协议层支持工具一样，yapi也提供了基于mockjs的响应内容生成方法，前后端的同事都可以了解下mockjs的语法以便修改接口文档的响应内容。

 

 

2.1 前端调用协议层的默认实现（yapi作为mockServer）
在上一步基础上,前端的同事通过代理的方式（如果是浏览器则使用fiddler或chales等工具改写请求规则，如果是node则通过相应的代理配置改写请求规则)访问yapi提供的mockServer服务,也就是将请求的地址由真实的服务器地址改写为mockServer的地址。

可参考<正确开启mockjs的三种姿势(https://www.cnblogs.com/soyxiaobi/p/9846057.html)第2.2节.

2.2
后端同事则根据接口文档实现协议层的业务功能，如有变动应及时通过前端并修正接口文档。

在这种并行开发过程中,前后端一般也会因为各种原因协调修改接口文档，这种沟通过程无可避免, 毕竟"个体和互动高于流程和工具"。

 

3
前后端联调。