先後分離的總結
咱們遇到了什麼問題？
1.前端沒法調試後端未完成的 API：若是後端同窗尚未完成 API 開發，那麼前端同窗就不能對這個 API 進行開發。以前咱們都是在代碼裏直接經過給變量賦假數據，又或者是在後端 Controller 裏直接 return JSON 的方式來進行調試的。這樣的方式很容易會出現的狀況就是，每次提交 commit 都要把它刪除掉，有時忘了沒有刪除掉，那麼提交歷史就會變得很髒。html
2.沒有自動化測試：前端對接口的調用沒有作自動化的測試。前端
3.前端須要依賴後端開發環境：前端須要後端環境來在本地測試，像咱們使用的方案就是 Vagrant + 虛擬機的來開發。這樣的方式其實很笨重，不但每次啓動虛擬機都得等一段時間，並且會佔用必定的 CPU 和內存資源，拖慢機器。然而，前端須要的只是數據。git
如何去解決這些問題？ ——先後端分離
大部分的互聯網公司都分紅了前端團隊和後端團隊。在軟件設計中，咱們有一個思想就是 Separation of Concerns (Soc)，也就是 關注點分離 的思想。既然咱們採用了先後端由不一樣團隊開發的模式，那麼咱們應該有分治的思想，也就是說，咱們要儘量更多地關注本身從事的領域。github
一.爲何要先後端分離？
1.框架層面express
先後端倉庫的分離：json
整個前端工程使用 git subtree從後端Git工程中切分出來。後端應用均使用同一個前端代碼庫。前端只clone前端代碼，啓動前端工程。前端使用sever來mock數據渲染ftl模板以及頁面展現segmentfault
2.開發層面後端
先後端約定好接口，各自開發；節約時間（但聯調的時間可能增長），接口有更新及時溝通api
上線能夠只上前端或後端代碼瀏覽器
二.如何實現先後端分離
怎麼作先後端分離，咱們認爲的先後端分離
前端：負責View和Controller層。
後端：負責Model層，業務處理/數據處理等。
試想一下，若是前端掌握了Controller，咱們能夠作url design，咱們能夠根據場景決定在服務端同步渲染，仍是根據view層數據輸出json數據，咱們還能夠根據表現層需求很容易的作 Bigpipe,Comet,Socket等等，徹底是需求決定使用方式。
實際上，如今不少的成熟的網站都沒有作到上面的設計，不少時候後端也負責一部分View的渲染，例如不少的後端模版，有的時候這是很須要的。因此咱們如今所談的先後端分離，更多的是基於上面咱們所遇到的問題出發，即基於現有的先後端共同渲染View，但前端又能獨立開發的優化角度出發。
方案一：採用 SPA 架構
業界不少公司會採用 SPA（Single Page Application，單頁應用）的架構，這種架構是自然的先後端分離的。全部的數據都是後端經過 JSON 的形式來傳遞到前端，前端自己也有本身的 MV* 框架，從物理上實現了先後端分離。
WEB服務中，SPA類佔的比例不多。不少場景下還有同步/同步+異步混合的模式，SPA不能做爲一種通用的解決方案。
方案二：淘寶 UED 的大前端方案（中途島）
上圖是淘寶基於Node的先後端分離分層，以及Node的職責範圍。簡單解釋下： －最上端是服務端，就是咱們常說的後端。後端對於咱們來講，就是一個接口的集合，服務端提供各類各樣的接口供咱們使用。由於有Node層，也不用侷限是什麼形式的服務。對於後端開發來講，他們只用關心業務代碼的接口實現。 －服務端下面是Node應用。 －Node應用中有一層Model Proxy與服務端進行通信。這一層主要目前是抹平咱們對不一樣接口的調用方式，封裝一些view層須要的Model。 －Node層還能輕鬆實現原來vmcommon,tms（引用淘寶內容管理系統）等需求。 －Node層要使用什麼框架由開發者本身決定。不過推薦使用express+xTemplate的組合，xTemplate能作到先後端公用。 －怎麼用Node你們本身決定，可是使人興奮的是，咱們終於可使用Node輕鬆實現咱們想要的輸出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、異步，想怎麼整就怎麼整，徹底根據你的場景決定。 －瀏覽器層在咱們這個架構中沒有變化，也不但願由於引入Node改變你之前在瀏覽器中開發的認知。 －引入Node，只是把本該就前端控制的部分交由前端掌控。
淘寶 UED 的大前端方案的思想是很是先進的，在前端 HTML/CSS/JS 和後端 Java 之間，架設了一層 NodeJS，把 View 層和 Controller 層都交由前端團隊去開發，後端團隊只負責 Modal 層。然而，這種方案對項目的改動將很是大，改形成本很是高。作到了真正的先後端分離。這並非咱們所要談論的。有興趣的能夠搜索下相關的文章。
方案三：構建 Mock Server
Mock Server 的概念很是簡單，就是在開發環境構建一個模擬的服務器，而後構建假數據（Mock Data），再利用構建的假數據來進行開發。
這種方法的好處：
靈活性高：它小到能夠只攔截一個 HTTP 請求，對某一個 API 進行調試；大到前端能夠徹底使用 Mock Server 進行開發，在本地徹底不須要跑後端服務器。因此它能夠以很是平滑柔和的方式融入到前端項目的開發當中。
構建簡單：咱們甚至只須要經過 Fiddler 或者 Charles 等抓包攔截軟件，就能夠完成一個 Mock Server 的構建。
能自動生成 API：因爲數據和接口都是肯定的，因此咱們能夠利用它來建立 API 文檔，便於先後端開發。
能爲自動化測試鋪路：一樣是因爲數據和接口都是肯定的，因此咱們還能夠利用它來作單元測試。
三.如何對咱們的項目進行改造？
四.具體的實現
咱們想要的Mock數據的樣子：
1.全工程的數據都要Mock； 2.在固定平臺上建立接口，接口的請求參數和返回參數靈活配置； 3.能經過簡單的命令實現數據的Mock； 4.只啓動前端工程，不啓動後端工程；
網上有不少的開源技術，能夠實現Mock數據的功能;
1.sosoapi
2.taobo rap的項目,RAP
上面開源技術的優缺點:
特色：友好的圖形界面，完整的接口文檔
缺點：接口徹底託管在網站上，安全隱患
簡單的數據僞造，只實現本地的數據僞造（無接口文檔）
1.Mock.js
2.faker.js
特色：安全性高，產生本地數據;根據語法產生對應的數據
缺點：無圖形界面，手動編寫接口文檔
不少時候，咱們寫單頁面應用時，都須要啓動一個本地sever，這裏推薦puer。簡而言之，Puer是一個能夠實時編輯刷新的前端服務器；同時它還兼有模擬數據的功能。
文檔型
特色：優美的接口文檔
缺點：無圖形界面，編寫文檔學習成本高；適合後端編寫接口文檔
總結:
若是要作工程性的，要創建起咱們開始介紹固定站點，圖形化錄入和展現接口；並創建起和工程結合的mock數據功能。
若是咱們只是開發單頁面應用，可使用Mock.js來模擬單一化的數據。
若是要寫接口文檔，建議使用apiary。
簡單的先作以上的介紹。