前后端分工协作是一个老生常谈的大话题,很多公司都在尝试用工程化的方式去提升前后端之间交流的效率,降低沟通成本,并且也开发了大量的工具。但是几乎没有一种方式是令双方都很满意的。事实上,也不可能让所有人都满意。根本原因还是前后端之间的交集不够大,交流的核心往往只限于接口及接口往外扩散的一部分。这也是为什么很多公司在招聘的时候希望前端人员熟练掌握一门后台语言,后端同学了解前端的相关知识。 一、开发流程 前端切完图,处理好接口信息,接着就是把静态demo交给后台去拼接,这是一般的流程。这种流程存在很多的缺陷。
当然,存在的问题远不止上面枚举的这些,这种传统的方式实在是不酷(Kimi 附身^_^)。还有一种开发流程,SPA(single page application),前后端职责相当清晰,后端给我接口,我全部用 ajax 异步请求,这种方式,在现代浏览器中可以使用 PJAX 稍微提高体验,Facebook 早在三四年前对这种 SPA 的模式提出了一套解决方案,quickling+bigpipe,解决了 SEO 以及数据吐出过慢的问题。他的缺点也是十分明显的:
问题多的已经是无力吐槽了,当然他依然有自己的优势,咱们也不能一票否决。 针对上面看到的问题,现在也有一些团队在尝试前后端之间加一个中间层(比如淘宝UED的 MidWay )。这个中间层由前端来控制。 +----------------+ | F2E | +---↑--------↑---+ | | +---↓--------↓---+ | Middle | +---↑--------↑---+ | | +---↓--------↓---+ | R2E | +----------------+ 中间层的作用就是为了更好的控制数据的输出,如果用MVC模型去分析这个接口,R2E(后端)只负责 M(数据) 这部分,Middle(中间层)处理数据的呈现(包括 V 和 C)。淘宝UED有很多类似的文章,这里不赘述。 二、核心问题 上面提出了在业务中看到的常见的三种模式,问题的核心就是数据交给谁去处理。数据交给后台处理,这是模式一,数据交给前端处理,这是模式二,数据交给前端分层处理,这是模式三。三种模式没有优劣之分,其使用还是得看具体场景。 既然都是数据的问题,数据从哪里来?这个问题又回到了接口。
这一系列的问题一直困扰着奋战在前线的前端工程师和后端开发者。淘宝团队做了两套接口文档的维护工具,IMS以及DIP,不知道有没有对外开放,两个东西都是基于 JSON Schema 的一个尝试,各有优劣。JSON Schema 是对 JSON 的一个规范,类似我们在数据库中创建表一样,对每个字段做一些限制,这里也是一样的原理,可以对字段进行描述,设置类型,限制字段属性等。 接口文档这个事情,使用 JSON Schema 可以自动化生产,所以只需编写 JSON Schema 而不存在维护问题,在写好的 Schema 中多加些限制性的参数,我们就可以直接根据 Schema 生成 mock(测试) 数据。 mock 数据的外部调用,这倒是很好处理:
在请求的参数中加入 callback 参数,如 /mock/hashString?cb=callback,一般的 io(ajax) 库都对异步数据获取做了封装,我们在测试的时候使用 jsonp,回头上线,将 dataType 改成 json 就行了。
这里略微麻烦的是 POST 方法,jsonp 只能使用 get 方式插入 script 节点去请求数据,但是 POST,只能呵呵了。 这里的处理也有多重方式可以参考:
对于如何拿到跨域的接口信息,我也给出几个参考方案:
php中处理就比较简单啦:
Ctrl+S,保存把线上的接口数据到本地的api文件夹吧-_-|| 三、小结 本文只是对前后端协作存在的问题和现有的几种常见模式做了简要的列举,JSON Schema 具体如何去运用,还有接口的维护问题、接口信息的获取问题没有具体阐述,这个后续有时间会整理下我对他的理解。
|
|