前后端分工協(xié)作是一個(gè)老生常談的大話題，很多公司都在嘗試用工程化的方式去提升前后端之間交流的效率，降低溝通成本，并且也開發(fā)了大量的工具。但是幾乎沒有一種方式是令雙方都很滿意的。事實(shí)上，也不可能讓所有人都滿意。根本原因還是前后端之間的交集不夠大，交流的核心往往只限于接口及接口往外擴(kuò)散的一部分。這也是為什么很多公司在招聘的時(shí)候希望前端人員熟練掌握一門后臺(tái)語言，后端同學(xué)了解前端的相關(guān)知識(shí)。

一、開發(fā)流程

前端切完圖，處理好接口信息，接著就是把靜態(tài)demo交給后臺(tái)去拼接，這是一般的流程。這種流程存在很多的缺陷。

• 后端同學(xué)對(duì)文件進(jìn)行拆分拼接的時(shí)候，由于對(duì)前端知識(shí)不熟悉，可能會(huì)搞出一堆bug，到最后又需要前端同學(xué)幫助分析原因，而前端同學(xué)又不是特別了解后端使用的模板，造成尷尬的局面。
• 如果前端沒有使用統(tǒng)一化的文件夾結(jié)構(gòu)，并且靜態(tài)資源（如圖片，css，js等）沒有剝離出來放到 CDN，而是使用相對(duì)路徑去引用，當(dāng)后端同學(xué)需要對(duì)靜態(tài)資源作相關(guān)配置時(shí)，又得修改各個(gè)link，script標(biāo)簽的src屬性，容易出錯(cuò)。
• 接口問題
  1. 后端數(shù)據(jù)沒有準(zhǔn)備好，前端需要自己模擬一套，成本高，如果后期接口有改變，自己模擬的那套數(shù)據(jù)又不行了。
  2. 后端數(shù)據(jù)已經(jīng)開發(fā)好，接口也準(zhǔn)備好了，本地需要代理線上數(shù)據(jù)進(jìn)行測(cè)試。這里有兩個(gè)費(fèi)神的地方，一是需要代理，否則可能跨域，二是接口信息如果改動(dòng)，后期接你項(xiàng)目的人需要改你的代碼，麻煩。
• 不方便控制輸出。為了讓首屏加載速度快一點(diǎn)，我們期望后端先吐出一點(diǎn)數(shù)據(jù)，剩下的才去 ajax 渲染，但讓后端吐出多少數(shù)據(jù)，我們不好控。

當(dāng)然，存在的問題遠(yuǎn)不止上面枚舉的這些，這種傳統(tǒng)的方式實(shí)在是不酷（Kimi 附身^_^）。還有一種開發(fā)流程，SPA（single page application），前后端職責(zé)相當(dāng)清晰，后端給我接口，我全部用 ajax 異步請(qǐng)求，這種方式，在現(xiàn)代瀏覽器中可以使用 PJAX 稍微提高體驗(yàn)，F(xiàn)acebook 早在三四年前對(duì)這種 SPA 的模式提出了一套解決方案，quickling+bigpipe，解決了 SEO 以及數(shù)據(jù)吐出過慢的問題。他的缺點(diǎn)也是十分明顯的：

• 頁面太重，前端渲染工作量也大
• 首屏還是慢
• 前后端模板復(fù)用不了
• SEO 依然很狗血（quickling 架構(gòu)成本高）
• history 管理麻煩

問題多的已經(jīng)是無力吐槽了，當(dāng)然他依然有自己的優(yōu)勢(shì)，咱們也不能一票否決。

針對(duì)上面看到的問題，現(xiàn)在也有一些團(tuán)隊(duì)在嘗試前后端之間加一個(gè)中間層（比如淘寶UED的 MidWay ）。這個(gè)中間層由前端來控制。

中間層的作用就是為了更好的控制數(shù)據(jù)的輸出，如果用MVC模型去分析這個(gè)接口，R2E（后端）只負(fù)責(zé) M（數(shù)據(jù)） 這部分，Middle（中間層）處理數(shù)據(jù)的呈現(xiàn)（包括 V 和 C）。淘寶UED有很多類似的文章，這里不贅述。

二、核心問題

上面提出了在業(yè)務(wù)中看到的常見的三種模式，問題的核心就是數(shù)據(jù)交給誰去處理。數(shù)據(jù)交給后臺(tái)處理，這是模式一，數(shù)據(jù)交給前端處理，這是模式二，數(shù)據(jù)交給前端分層處理，這是模式三。三種模式?jīng)]有優(yōu)劣之分，其使用還是得看具體場(chǎng)景。

既然都是數(shù)據(jù)的問題，數(shù)據(jù)從哪里來？這個(gè)問題又回到了接口。

• 接口文檔由誰來撰寫和維護(hù)？
• 接口信息的改動(dòng)如何向前后端傳遞？
• 如何根據(jù)接口規(guī)范拿到前后端可用的測(cè)試數(shù)據(jù)？
• 使用哪種接口？JSON，JSONP？
• JSONP 的安全性問題如何處理？

這一系列的問題一直困擾著奮戰(zhàn)在前線的前端工程師和后端開發(fā)者。淘寶團(tuán)隊(duì)做了兩套接口文檔的維護(hù)工具，IMS以及DIP，不知道有沒有對(duì)外開放，兩個(gè)東西都是基于 JSON Schema 的一個(gè)嘗試，各有優(yōu)劣。JSON Schema 是對(duì) JSON 的一個(gè)規(guī)范，類似我們?cè)跀?shù)據(jù)庫中創(chuàng)建表一樣，對(duì)每個(gè)字段做一些限制，這里也是一樣的原理，可以對(duì)字段進(jìn)行描述，設(shè)置類型，限制字段屬性等。

接口文檔這個(gè)事情，使用 JSON Schema 可以自動(dòng)化生產(chǎn)，所以只需編寫 JSON Schema 而不存在維護(hù)問題，在寫好的 Schema 中多加些限制性的參數(shù)，我們就可以直接根據(jù) Schema 生成 mock（測(cè)試） 數(shù)據(jù)。

mock 數(shù)據(jù)的外部調(diào)用，這倒是很好處理：

在請(qǐng)求的參數(shù)中加入 callback 參數(shù)，如 /mock/hashString?cb=callback，一般的 io(ajax) 庫都對(duì)異步數(shù)據(jù)獲取做了封裝，我們?cè)跍y(cè)試的時(shí)候使用 jsonp，回頭上線，將 dataType 改成 json 就行了。

這里略微麻煩的是 POST 方法，jsonp 只能使用 get 方式插入 script 節(jié)點(diǎn)去請(qǐng)求數(shù)據(jù)，但是 POST，只能呵呵了。

這里的處理也有多重方式可以參考：

• 修改 Hosts，讓 mock 的域名指向開發(fā)域名
• mock 設(shè)置 header 響應(yīng)頭，Access-Allow-Origin-Control

對(duì)于如何拿到跨域的接口信息，我也給出幾個(gè)參考方案：

• fiddler 替換包，好像是支持正則的，感興趣的可以研究下（求分享研究結(jié)果，因?yàn)槲覜]找到正則的設(shè)置位置）
• 使用 HTTPX 或者其他代理工具，原理和 fiddler 類似，不過可視化效果（體驗(yàn)）要好很多，畢竟人家是專門做代理用的。
• 自己寫一段腳本代理，也就是本地開一個(gè)代理服務(wù)器，這里需要考慮端口的占用問題。其實(shí)我不推薦監(jiān)聽端口，一個(gè)比較不錯(cuò)的方案是本地請(qǐng)求全部指向一個(gè)腳本文件，然后腳本轉(zhuǎn)發(fā)URL，如：

• php中處理就比較簡(jiǎn)單啦：

• Ctrl+S,保存把線上的接口數(shù)據(jù)到本地的api文件夾吧-_-||

三、小結(jié)

本文只是對(duì)前后端協(xié)作存在的問題和現(xiàn)有的幾種常見模式做了簡(jiǎn)要的列舉，JSON Schema 具體如何去運(yùn)用，還有接口的維護(hù)問題、接口信息的獲取問題沒有具體闡述，這個(gè)后續(xù)有時(shí)間會(huì)整理下我對(duì)他的理解。