談談先後端的分工協做

原文出處： 小鬍子哥的博客（@Barret李靖）

先後端分工協做是一個老生常談的大話題，不少公司都在嘗試用工程化的方式去提高先後端之間交流的效率，下降溝通成本，而且也開發了大量的工具。可是幾乎沒有一種方式是令雙方都很滿意的。事實上，也不可能讓全部人都滿意。根本緣由仍是先後端之間的交集不夠大，交流的核心每每只限於接口及接口往外擴散的一部分。這也是爲何不少公司在招聘的時候但願前端人員熟練掌握一門後臺語言，後端同窗瞭解前端的相關知識。

1、開發流程

前端切完圖，處理好接口信息，接着就是把靜態demo交給後臺去拼接，這是通常的流程。這種流程存在不少的缺陷。

後端同窗對文件進行拆分拼接的時候，因爲對前端知識不熟悉，可能會搞出一堆bug，到最後又須要前端同窗幫助分析緣由，而前端同窗又不是特別瞭解後端使用的模板，形成尷尬的局面。

若是前端沒有使用統一化的文件夾結構，而且靜態資源（如圖片，css，js等）沒有剝離出來放到 CDN，而是使用相對路徑去引用，當後端同窗須要對靜態資源做相關配置時，又得修改各個link，script標籤的src屬性，容易出錯。

接口問題
後端數據沒有準備好，前端須要本身模擬一套，成本高，若是後期接口有改變，本身模擬的那套數據又不行了。

後端數據已經開發好，接口也準備好了，本地須要代理線上數據進行測試。這裏有兩個費神的地方，一是須要代理，不然可能跨域，二是接口信息若是改動，後期接你項目的人須要改你的代碼，麻煩。

不方便控制輸出。爲了讓首屏加載速度快一點，咱們指望後端先吐出一點數據，剩下的纔去 ajax 渲染，但讓後端吐出多少數據，咱們很差控。

固然，存在的問題遠不止上面枚舉的這些，這種傳統的方式實在是不酷（Kimi 附身^_^）。還有一種開發流程，SPA（single page application），先後端職責至關清晰，後端給我接口，我所有用 ajax 異步請求，這種方式，在現代瀏覽器中可使用 PJAX 稍微提升體驗，Facebook 早在三四年前對這種 SPA 的模式提出了一套解決方案，quickling+bigpipe，解決了 SEO 以及數據吐出過慢的問題。他的缺點也是十分明顯的：

頁面過重，前端渲染工做量也大
首屏仍是慢
先後端模板複用不了
SEO 依然很狗血（quickling 架構成本高）
history 管理麻煩
問題多的已是無力吐槽了，固然他依然有本身的優點，我們也不能一票否決。

針對上面看到的問題，如今也有一些團隊在嘗試先後端之間加一箇中間層（好比淘寶UED的 MidWay ）。這個中間層由前端來控制。

JavaScript

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

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

中間層的做用就是爲了更好的控制數據的輸出，若是用MVC模型去分析這個接口，R2E（後端）只負責 M（數據） 這部分，Middle（中間層）處理數據的呈現（包括 V 和 C）。淘寶UED有不少相似的文章，這裏不贅述。

2、核心問題

上面提出了在業務中看到的常見的三種模式，問題的核心就是數據交給誰去處理。數據交給後臺處理，這是模式一，數據交給前端處理，這是模式二，數據交給前端分層處理，這是模式三。三種模式沒有優劣之分，其使用仍是得看具體場景。

既然都是數據的問題，數據從哪裏來？這個問題又回到了接口。

接口文檔由誰來撰寫和維護？
接口信息的改動如何向先後端傳遞？
如何根據接口規範拿到先後端可用的測試數據？
使用哪一種接口？JSON，JSONP？
JSONP 的安全性問題如何處理？
這一系列的問題一直困擾着奮戰在前線的前端工程師和後端開發者。淘寶團隊作了兩套接口文檔的維護工具，IMS以及DIP，不知道有沒有對外開放，兩個東西都是基於 JSON Schema 的一個嘗試，各有優劣。JSON Schema 是對 JSON 的一個規範，相似咱們在數據庫中建立表同樣，對每一個字段作一些限制，這裏也是同樣的原理，能夠對字段進行描述，設置類型，限制字段屬性等。

接口文檔這個事情，使用 JSON Schema 能夠自動化生產，因此只需編寫 JSON Schema 而不存在維護問題，在寫好的 Schema 中多加些限制性的參數，咱們就能夠直接根據 Schema 生成 mock（測試） 數據。

mock 數據的外部調用，這卻是很好處理：

JavaScript

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

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

在請求的參數中加入 callback 參數，如 /mock/hashString?cb=callback，通常的 io(ajax) 庫都對異步數據獲取作了封裝，咱們在測試的時候使用 jsonp，回頭上線，將 dataType 改爲 json 就好了。

JavaScript

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

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，如：
JavaScript

原始請求：http://barretlee.com/api/test...
在ajax請求的時候：

$.ajax({
  url: "http://<local>/api.php?path=/api/text.json"
});

原始請求：http://barretlee.com/api/test.json
在ajax請求的時候：
$.ajax({
  url: "http://<local>/api.php?path=/api/text.json"
});
php中處理就比較簡單啦：
JavaScript

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

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

Ctrl+S,保存把線上的接口數據到本地的api文件夾吧-_-||
3、小結

本文只是對先後端協做存在的問題和現有的幾種常見模式作了簡要的列舉，JSON Schema 具體如何去運用，還有接口的維護問題、接口信息的獲取問題沒有具體闡述，這個後續有時間會整理下我對他的理解。