前端架构之路（2） - 本地化接口模拟、先后端并行开发

时间 2019-11-05 标签前端架构之路本地化接口模拟后端并行开发

本地化接口模拟、先后端并行开发

1. 为何须要 “本地化接口模拟、先后端并行开发”

在先后端分离以前，先后端的数据交流以及页面渲染使用后端的模板（如 java > jsp、php > smarty）是很常见的，因此前端对页面的开发与调试老是依赖后端程序，而不能本地运行，这就致使前端开发很耗时，而且毫无心义。先后端分离以后，前端可以在本地运行服务程序、开发、调试，这让前端开发人员从与后端耦合开发的过程当中解脱出来，更高效快捷的开发 web 前端程序。基于此，咱们便有了“本地化接口模拟”的需求。php

2. 本地化接口模拟

这就是说咱们要在本地模拟一个与服务器差很少的环境，可以提供数据所需的接口，进行错误模拟处理等等。html

通常来讲，本地数据模拟的解决方案有两种思路：前端

同等模拟服务器环境，就是依据文档，彻底按照服务器的接口配置搭建本地的接口服务；
多环境配置&切换，就是从代码的层面配置多个环境（如线上环境，本地环境），根据是在线上仍是在本地切换不一样的环境。

2.1 同等模拟服务器环境

这种方式基本上不须要在代码层面作更改，由于本地接口与服务器接口基本上一致，包括接口名称，请求方法，请求参数，响应数据。java

这种思路的解决方案不少，比较典型的有：git

RAML(RESTful API Modeling Language 即 RESTful API 建模语言)：

基于 YAML，帮助设计 RESTful API 和鼓励对API的发掘和重用，解析并自动生成对应的客户端调用代码、服务端代码结构, API说明文档。github

这个工具强能很强大，本地化接口模拟只是其中的一个功能。web

Swagger：

基于 JSON 进行文档定义的一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。ajax

也是一个功能很强大的工具，本地化接口模拟也只是其中的一个功能。与RAML相比，RAML解决的问题是设计阶段的问题，而Swagger则是侧重解决现有API的文档问题，它们最大的不一样是RAML须要单独维护一套文档，而Swagger则是经过一套反射机制从代码中生成文档，而且借助ajax能够直接在文档中对API进行交互。json

API Blueprint：

基于 Markdown 的一套 API 描述标准，使用工具能够把标记文稿转换成漂亮的接口文档，并提供本地化接口模拟功能。后端

由于是基于 Markdown，因此使用门槛比前二者低了不少，但功能不及前二者强大。

2.2 多环境配置&切换

这种方式是在代码的层面配置多个环境（如线上环境，本地环境），根据是在线上仍是在本地切换不一样的环境。

好比，开发的时候切换到本地环境，线上运行的时候切换到线上环境（若是有须要，能够配置更多环境）。在本地环境接口都是采用的本地化模拟的接口，而线上环境接口则是线上实际运行的接口。这样作的好处是：

能够把应用对接口的实现进行一次封装隔离，如此，若是接口有任何改动，咱们只须要改封装隔离的代码，而不须要动其余地方的代码，这在大型应用中尤其突出；
可以更好的管理代码，而且一目了然当前页面有多少接口，更具可读性和移植性。

未封装隔离的实现（以 `jQuery.ajax` 为例）：

// file1.js
$.getJSON('/api/v1/home/index/list', {keyA: 'valueA', keyB, 'valueB'}, res => {...});

// file2.js
$.getJSON('/api/v1/home/index/add', {keyC: 'valueC', keyD, 'valueD'}, res => {...});

...

若是应用比较小，接口实现比较少，其实也没什么问题，但若是是复杂应用中，当接口名称、请求方法、请求参数或返回数据字段发生变化，这个时候就须要处处去找使用的地方，而后处处改。这个时候就须要对接口进行封装隔离了。

对接口进行封装隔离，以 see-ajax（对 ajax 的封装）, see-fetch（对 fetch 的封装）为例：

// ajax1.js （0：线上环境，1：本地环境）
seeAjax.config('list', {
    method: [
        'post' // 线上环境使用 post 方法，本地使用默认的 get 方法
    ],
    stringify: [
        true  // 线上环境序列化请求参数
    ],
    settings: [
        // 自定义 ajax 配置
    ],
    url: [
        'online url',
        'local url'
    ],
    requestKeys: [
        {
            keyA: 'keyF' // 线上环境下把请求 {keyA: 'valueA'} 映射成 {keyF: 'valueA'}
        }
    ],
    responseRefactor: [
        // json 格式化
    ],
    preHandle: [
        // 请求发出以前对本次请求参数的更多操做，如添加、修改
    ],
    postHandle: [
        // 响应以后的操做
    ],
    implement: [
        // 自定义实现接口
    ],
    implementDelay: [...] // milliseconds delay for implement
});


// file1.js
seeAjax('list', {keyA: 'valueA', keyB, 'valueB'}, res => {...});

...

这样作，即便接口有变化，只须要改 ajax1.js 文件中对名为 list 请求的配置（包括请求方法，是否序列化请求参数，重定请求键名，格式化响应数据等等），而不须要改其余调用这个接口的地方。

2.3 二者配合使用

本地化接口模拟这两种方式是从不一样的角度出发给出的解决方案，能够配合在一块儿使用。

3. 先后端并行开发

正常状况下，前端的开发在完成 UI 或者组件开发以后，就须要等后端给出接口文档才能继续进行，这对项目无疑是延长了开发周期，因此若是能作到先后端并行开发，就比较完美了。

先后端并行开发，就是说前端的开发不须要等后端给出接口文档就能够进行开发，等后端给出接口以后，再对接好后就基本上能够上线了。在本地化接口模拟的实现下，咱们就能够作到先后端并行开发了。

仍是以 see-ajax, see-fetch 为例：

开发过程当中预约 3 个环境：0（线上环境），1（本地模拟后台接口环境），2（并行开发环境）

并行开发环境：并行开发的时候，预约好本身想要的接口，须要传给后端的请求参数，以及须要的响应数据；
本地模拟后台接口环境：与后台对接的时候，开启本地模拟后台接口环境，经过对请求进行配置，给到后端想要的数据，获取本身想要的数据；
- 经过 method 配置请求方法
- 经过 stringify 配置是否序列化请求参数
- 经过 url 配置请求地址
- 经过 requestKeys 配置请求参数改名
- 经过 responseRefactor 配置对响应数据进行格式化
- 经过 preHandle 配置请求发出以前对本次请求参数的更多操做，如添加、修改
- 经过 postHandle 配置响应以后的操做
- ...
线上环境：通常来讲对接完后要进行线上调试，此时的线上调试的工做量较以前已经大大的较低了。