前后端分工协作是一个老生常谈的大话题，很多公司都在尝试用工程化的方式去提升前后端之间交流的效率，降低沟通成本，并且也开发了大量的工具。但是几乎没有一种方式是令双方都很满意的。事实上，也不可能让所有人都满意。根本原因还是前后端之间的交集不够大，交流的核心往往只限于接口及接口往外扩散的一部分。这也是为什么很多公司在招聘的时候希望前端人员熟练掌握一门后台语言，后端同学了解前端的相关知识。

一、开发流程

前端切完图，处理好接口信息，接着就是把静态demo交给后台去拼接，这是一般的流程。这种流程存在很多的缺陷。

  • 后端同学对文件进行拆分拼接的时候，由于对前端知识不熟悉，可能会搞出一堆bug，到最后又需要前端同学帮助分析原因，而前端同学又不是特别了解后端使用的模板，造成尴尬的局面。
  • 如果前端没有使用统一化的文件夹结构，并且静态资源（如图片，css，js等）没有剥离出来放到 CDN，而是使用相对路径去引用，当后端同学需要对静态资源作相关配置时，又得修改各个link，script标签的src属性，容易出错。
  • 接口问题
    1. 后端数据没有准备好，前端需要自己模拟一套，成本高，如果后期接口有改变，自己模拟的那套数据又不行了。
    2. 后端数据已经开发好，接口也准备好了，本地需要代理线上数据进行测试。这里有两个费神的地方，一是需要代理，否则可能跨域，二是接口信息如果改动，后期接你项目的人需要改你的代码，麻烦。
  • 不方便控制输出。为了让首屏加载速度快一点，我们期望后端先吐出一点数据，剩下的才去 ajax 渲染，但让后端吐出多少数据，我们不好控。

当然，存在的问题远不止上面枚举的这些，这种传统的方式实在是不酷（Kimi 附身^_^）。还有一种开发流程，SPA（single page application），前后端职责相当清晰，后端给我接口，我全部用 ajax 异步请求，这种方式，在现代浏览器中可以使用 PJAX 稍微提高体验，Facebook 早在三四年前对这种 SPA 的模式提出了一套解决方案，quickling+bigpipe，解决了 SEO 以及数据吐出过慢的问题。他的缺点也是十分明显的：

  • 页面太重，前端渲染工作量也大
  • 首屏还是慢
  • 前后端模板复用不了
  • SEO 依然很狗血（quickling 架构成本高）
  • history 管理麻烦

问题多的已经是无力吐槽了，当然他依然有自己的优势，咱们也不能一票否决。

针对上面看到的问题，现在也有一些团队在尝试前后端之间加一个中间层（比如淘宝UED的 MidWay ）。这个中间层由前端来控制。

+----------------+
|       F2E      |
+---↑--------↑---+
    |        |
+---↓--------↓---+
|     Middle     |
+---↑--------↑---+
    |        |
+---↓--------↓---+
|       R2E      |
+----------------+

中间层的作用就是为了更好的控制数据的输出，如果用MVC模型去分析这个接口，R2E（后端）只负责 M（数据） 这部分，Middle（中间层）处理数据的呈现（包括 V 和 C）。淘宝UED有很多类似的文章，这里不赘述。

二、核心问题

上面提出了在业务中看到的常见的三种模式，问题的核心就是数据交给谁去处理。数据交给后台处理，这是模式一，数据交给前端处理，这是模式二，数据交给前端分层处理，这是模式三。三种模式没有优劣之分，其使用还是得看具体场景。

既然都是数据的问题，数据从哪里来？这个问题又回到了接口。

  • 接口文档由谁来撰写和维护？
  • 接口信息的改动如何向前后端传递？
  • 如何根据接口规范拿到前后端可用的测试数据？
  • 使用哪种接口？JSON，JSONP？
  • JSONP 的安全性问题如何处理？

这一系列的问题一直困扰着奋战在前线的前端工程师和后端开发者。淘宝团队做了两套接口文档的维护工具，IMS以及DIP，不知道有没有对外开放，两个东西都是基于 JSON Schema 的一个尝试，各有优劣。JSON Schema 是对 JSON 的一个规范，类似我们在数据库中创建表一样，对每个字段做一些限制，这里也是一样的原理，可以对字段进行描述，设置类型，限制字段属性等。

接口文档这个事情，使用 JSON Schema 可以自动化生产，所以只需编写 JSON Schema 而不存在维护问题，在写好的 Schema 中多加些限制性的参数，我们就可以直接根据 Schema 生成 mock（测试） 数据。

mock 数据的外部调用，这倒是很好处理：

typeof callback === "function" && callback({
   json: "jsonContent"
})

在请求的参数中加入 callback 参数，如 /mock/hashString?cb=callback，一般的 io(ajax) 库都对异步数据获取做了封装，我们在测试的时候使用 jsonp，回头上线，将 dataType 改成 json 就行了。

IO({
  url: "http://barretlee.com",
  dataType: "jsonp", //json
  success: function(){}
})

这里略微麻烦的是 POST 方法，jsonp 只能使用 get 方式插入 script 节点去请求数据，但是 POST，只能呵呵了。

这里的处理也有多重方式可以参考：

  • 修改 Hosts，让 mock 的域名指向开发域名
  • mock 设置 header 响应头，Access-Allow-Origin-Control

对于如何拿到跨域的接口信息，我也给出几个参考方案：

  • fiddler 替换包，好像是支持正则的，感兴趣的可以研究下（求分享研究结果，因为我没找到正则的设置位置）
  • 使用 HTTPX 或者其他代理工具，原理和 fiddler 类似，不过可视化效果（体验）要好很多，毕竟人家是专门做代理用的。
  • 自己写一段脚本代理，也就是本地开一个代理服务器，这里需要考虑端口的占用问题。其实我不推荐监听端口，一个比较不错的方案是本地请求全部指向一个脚本文件，然后脚本转发URL，如：
    原始请求：http://barretlee.com/api/test.json
    在ajax请求的时候：
    $.ajax({
      url: "http://<local>/api.php?path=/api/text.json"
    });

    php中处理就比较简单啦：

    if(!isset($_GET["page"])){
      echo 0;
      exit();
    }
    echo file_get_contents($_GET["path"]);

  • Ctrl+S,保存把线上的接口数据到本地的api文件夹吧-_-||

三、小结

本文只是对前后端协作存在的问题和现有的几种常见模式做了简要的列举，JSON Schema 具体如何去运用，还有接口的维护问题、接口信息的获取问题没有具体阐述，这个后续有时间会整理下我对他的理解。