人生三問以前後端分離是什麼鬼？

隨着互聯網的高速發展，前端頁面的展現、交互體驗愈來愈靈活、炫麗，響應體驗也要求愈來愈高，後端服務的高併發、高可用、高性能、高擴展等特性的要求也越發苛刻，從而致使先後端研發各自專一於本身擅長的領域深耕細做。

然而帶來的另外一個問題：先後端的對接界面雙方卻關注甚少，沒有任何接口約定規範狀況下各自幹各自的，致使咱們在產品項目開發過程當中，先後端的接口聯調對接工做量佔比在30%-50%左右，甚至會更高。每每先後端接口聯調對接及系統間的聯調對接都是整個產品項目研發的軟肋。

本文的主要初衷就是規範約定先行，儘可能避免溝通聯調產生的沒必要要的問題，讓你們身心愉快地專一於各自擅長的領域。

爲什麼要分離

參考兩篇文章：

http://blog.jobbole.com/65509/

http://blog.jobbole.com/56161/

目前現有先後端開發模式：「後端爲主的MVC時代」，以下圖所示：

後端爲主的MVC時代

代碼可維護性獲得明顯好轉，MVC 是個很是好的協做模式，從架構層面讓開發者懂得什麼代碼應該寫在什麼地方。爲了讓 View 層更簡單幹脆，還能夠選擇 Velocity、Freemaker 等模板，使得模板裏寫不了 Java 代碼。

看起來是功能變弱了，但正是這種限制使得先後端分工更清晰。然而依舊並非那麼清晰，這個階段的典型問題是：

前端開發重度依賴開發環境，開發效率低。

這種架構下，先後端協做有兩種模式：一種是前端寫demo，寫好後，讓後端去套模板 。淘寶早期包括如今依舊有大量業務線是這種模式。好處很明顯，demo 能夠本地開發，很高效。不足是還須要後端套模板，有可能套錯，套完後還須要前端肯定，來回溝通調整的成本比較大。

另外一種協做模式是前端負責瀏覽器端的全部開發和服務器端的 View 層模板開發，支付寶是這種模式。好處是 UI 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成爲影響前端開發效率的重要因素。

先後端職責依舊糾纏不清。

Velocity 模板仍是蠻強大的，變量、邏輯、宏等特性，依舊能夠經過拿到的上下文變量來實現各類業務邏輯。這樣，只要前端弱勢一點，每每就會被後端要求在模板層寫出很多業務代碼。還有一個很大的灰色地帶是 Controller，頁面路由等功能本應該是前端最關注的，但倒是由後端來實現。Controller 自己與 Model 每每也會糾纏不清，看了讓人咬牙的業務代碼常常會出如今 Controller 層。這些問題不能全歸結於程序員的素養，不然 JSP 就夠了。

對前端發揮的侷限。

性能優化若是隻在前端作空間很是有限，因而咱們常常須要後端合做才能碰撞出火花，但因爲後端框架限制，咱們很難使用Comet、Bigpipe等技術方案來優化性能。

總上所述，就跟爲什麼要代碼重構同樣：

關注點分離

職責分離

對的人作對的事

更好的共建模式

快速的反應變化

什麼是分離

咱們如今要作的先後分離第一階段：「基於 Ajax 帶來的 SPA 時代」，如圖：

基於 Ajax 帶來的 SPA 時代

這種模式下，先後端的分工很是清晰，先後端的關鍵協做點是 Ajax 接口。看起來是如此美妙，但回過頭來看看的話，這與 JSP 時代區別不大。複雜度從服務端的 JSP 裏移到了瀏覽器的 JavaScript，瀏覽器端變得很複雜。相似 Spring MVC，這個時代開始出現瀏覽器端的分層架構：

瀏覽器端的分層架構

對於這一SPA階段，先後端分離有幾個重要挑戰：

先後端接口的約定。

若是後端的接口一塌糊塗，若是後端的業務模型不夠穩定，那麼前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉澱接口，==在阿里，很多團隊也有相似嘗試，經過接口規則、接口平臺等方式來作。有了和後端一塊兒沉澱的接口規則，還能夠用來模擬數據，使得先後端能夠在約定接口後實現高效並行開發。== 相信這一塊會越作越好。

前端開發的複雜度控制。

SPA 應用大多以功能交互型爲主，JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織，與 View 層的綁定等，都不是容易的事情。典型的解決方案是業界的 Backbone，但 Backbone 作的事還頗有限，依舊存在大量空白區域須要挑戰。

如何作分離

4.1 職責分離

職責分離

先後端僅僅經過異步接口(AJAX/JSONP)來編程

先後端都各自有本身的開發流程，構建工具，測試集合

關注點分離，先後端變得相對獨立並鬆耦合

4.2 開發流程

後端編寫和維護接口文檔，在 API 變化時更新接口文檔

後端根據接口文檔進行接口開發

前端根據接口文檔進行開發 + Mock平臺

開發完成後聯調和提交測試

Mock 服務器根據接口文檔自動生成 Mock 數據，實現了接口文檔即API：

開發流程

4.3 具體實施

如今已基本完成了，接口方面的實施：

接口文檔服務器：可實現接口變動實時同步給前端展現；

Mock接口數據平臺：可實現接口變動實時Mock數據給前端使用；

接口規範定義：很重要，接口定義的好壞直接影響到前端的工做量和實現邏輯；具體定義規範見下節；

接口文檔+Mock平臺服務器

接口規範V1.0.0

5.1 規範原則

接口返回數據即顯示：前端僅作渲染邏輯處理；

渲染邏輯禁止跨多個接口調用；

前端關注交互、渲染邏輯，儘可能避免業務邏輯處理的出現；

請求響應傳輸數據格式：JSON，JSON數據儘可能簡單輕量，避免多級JSON的出現；

5.2 基本格式

5.2.1 請求基本格式

GET請求、POST請求==必須包含key爲body的入參，全部請求數據包裝爲JSON格式，並存放到入參body中==，示例以下：

GET請求：

xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

POST請求：

5.2.2 響應基本格式

{

code: 200,

data: {

message: "success"

}

}

code : 請求處理狀態

200: 請求處理成功

500: 請求處理失敗

401: 請求未認證，跳轉登陸頁

406: 請求未受權，跳轉未受權提示頁

data.message: 請求處理消息

code=200 且 data.message="success": 請求處理成功

code=200 且 data.message!="success": 請求處理成功, 普通消息提示：message內容

code=500: 請求處理失敗，警告消息提示：message內容

5.3 響應實體格式

{

code: 200,

data: {

message: "success",

entity: {

id: 1,

name: "XXX",

code: "XXX"

}

}

}

data.entity: 響應返回的實體數據

5.4 響應列表格式

data.list: 響應返回的列表數據

5.5 響應分頁格式

{

code: 200,

data: {

recordCount: 2,

message: "success",

totalCount: 2,

pageNo: 1,

pageSize: 10,

list: [

{

id: 1,

name: "XXX",

code: "H001"

},

{

id: 2,

name: "XXX",

code: "H001"

} ],

totalPage: 1

}

}

data.recordCount: 當前頁記錄數

data.totalCount: 總記錄數

data.pageNo: 當前頁碼

data.pageSize: 每頁大小

data.totalPage: 總頁數

5.6 特殊內容規範

5.6.1 下拉框、複選框、單選框

由後端接口統一邏輯斷定是否選中，經過isSelect標示是否選中，示例以下：

{

code: 200,

data: {

message: "success",

list: [{

id: 1,

name: "XXX",

code: "XXX",

isSelect: 1

}, {

id: 1,

name: "XXX",

code: "XXX",

isSelect: 0

}]

}

}

禁止下拉框、複選框、單選框斷定選中邏輯由前端來處理，統一由後端邏輯斷定選中返回給前端展現；

5.6.2 Boolean類型

關於Boolean類型，JSON數據傳輸中一概使用1/0來標示，1爲是/True，0爲否/False；

5.6.3 日期類型

關於日期類型，JSON數據傳輸中一概使用字符串，具體日期格式因業務而定；

將來的大前端

目前咱們如今用的先後端分離模式屬於第一階段，因爲使用到的一些技術jquery等，對於一些頁面展現、數據渲染仍是比較複雜，不可以很好的達到複用。對於前端仍是有很大的工做量。

下一階段能夠在前端工程化方面，對技術框架的選擇、前端模塊化重用方面，可多作考量。也就是要迎來「==前端爲主的 MV* 時代==」。大多數的公司也基本都處於這個分離階段。

最後階段就是==Node 帶來的全棧時代==，徹底有前端來控制頁面，URL，Controller，路由等，後端的應用就逐步弱化爲真正的數據服務+業務服務，作且僅能作的是提供數據、處理業務邏輯，關注高可用、高併發等。