前后分離的總結
我們遇到了什么問題？
1.前端無法調試后端未完成的 API：如果后端同學還沒有完成 API 開發，那么前端同學就不能對這個 API 進行開發。之前我們都是在代碼里直接通過給變量賦假數據，又或者是在后端 Controller 里直接 return JSON 的方式來進行調試的。這樣的方式很容易會出現的情況就是，每次提交 commit 都要把它刪除掉，有時忘了沒有刪除掉，那么提交歷史就會變得很臟。
2.沒有自動化測試：前端對接口的調用沒有做自動化的測試。
3.前端需要依賴后端開發環境：前端需要后端環境來在本地測試，像我們使用的方案就是 Vagrant + 虛擬機的來開發。這樣的方式其實很笨重，不但每次啟動虛擬機都得等一段時間，而且會占用一定的 CPU 和內存資源，拖慢機器。然而，前端需要的只是數據。
如何去解決這些問題？ ——前后端分離
大部分的互聯網公司都分成了前端團隊和后端團隊。在軟件設計中，我們有一個思想就是 Separation of Concerns (Soc)，也就是 關注點分離 的思想。既然我們采用了前后端由不同團隊開發的模式，那么我們應該有分治的思想，也就是說，我們要盡可能更多地關注自己從事的領域。
一.為什么要前后端分離？
1.框架層面
前后端倉庫的分離：
整個前端工程使用 git subtree從后端Git工程中切分出來。后端應用均使用同一個前端代碼庫。前端只clone前端代碼，啟動前端工程。前端使用sever來mock數據渲染ftl模板以及頁面展示
2.開發層面
前后端約定好接口，各自開發；節約時間（但聯調的時間可能增加），接口有更新及時溝通
上線可以只上前端或后端代碼
二.如何實現前后端分離
怎么做前后端分離，我們認為的前后端分離
前端：負責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。
簡單的先做以上的介紹。