先后端分离的问题与解决方案

这些天项目有的API出现版本控制问题，着实忙乎了一小阵，由于项目使用TP5的传统方法进行版本控制（api目录下进行版本区分，由请求路径决定使用的版本）

可是问题每每是，项目使用了v2版本,可是后端又新建了v3，而前端不知情，因此也趁着此次机会，探索了较为实用的先后端分离问题与解决方案，并作整理。

较明显的问题

1.后端 API 产能难免，供给不上的问题
2.后端 API 出现 BUG，须要等待修复的问题
3.先后端沟通差别致使API实现的误差
4.后端 API 发生了修改，没有通知到前端，showcase 的时候发现了 bug

问题1解决方案

1.后端规范功能函数集、功能模块集、统一返回格式与方法、提升代码复用率，从而提升后端API产能问题

问题2解决方案

1.API出现BUG，前端提出BUG，并设置修复期限、BUG等级、修复奖励记录
2.API从完成到正式使用有三天使用内测期，内测期内前端发现BUG有奖励记录
3.前端内测期外的API出现BUG次数做限制，超过则惩罚记录
4.后端内测期外的API出现BUG次数做限制，超过则惩罚记录

问题3解决方案

使用API敏捷原型开发方法：
--前端构造理想IO，即参数，返回数据格式等等(半天)
--后端思考实现可行性，调整IO(半天)
--后端实现API(协商时间)，锁定API版本(具体实现参考下面方案)

问题4解决方案

实现一个简易型的消息系统（咱们使用了基于swoole实现的websocket，具体可参考个人开源小框架）

1.后端
--API完成
--与前端确认OK，则API锁定版本V1.0（自动记录锁定状况到日志）

2.需求变化/其余变更
--解锁API（自动通知前端,XXAPI版本解锁了），不解锁则没法提交成功
--修改完成后更新API版本，重复步骤1便可

API锁定与版本更新实现方案

概念

• API版本解锁：每一个API文件方法头标明版本号，每次修改需修改版本号，即为解锁。
• API版本升级：每一个API文件方法头标明版本号，每次修改需修改版本号大于原版本号，即为版本升级。

实现步骤

1.全部API按特定模块归类，例如admin后台模块，在API目录里编写相应的各个API文件，或如上图进行区分
2.记录全部模块API目录的路径到脚本，在开发人员提交的时候对这些路径进行检查
3.编写检查API的脚本，工做流程以下：提交时钩子检查API文件里的API方法是否无解锁的状况下被修改，即提交的文件若是是API目录下的API文件，则该文件方法注释里的版本号是否与原函数一致，一致且函数内容不同，提交失败并提示
4.若是提交的API文件版本大于原版本，短信通知过前端，提交成功

建议

提交代码时共触发两个脚本，一个作检查，一个作记录（记录前端人员的电话，API目录）

以上为粗略说明，如有错误与更好建议，请留言反馈，谢谢。

创做不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
基于swoole的实时消息通讯框架
基于Fastadmin整合阿里云OSS,Redis,物流，短信的后台系统