文章來自簡書：https://www.jianshu.com/p/f1287e1aee50
在網站開發過程中，對於前后端的分界線似乎一直是眾說紛紜。從一開始完全沒有前后端的概念，到后來的糾纏不清。
傳統的分離方法
在我的腦海中一提到前端和后端，基本上第一個出現的區別點就是:后端是跟數據庫跟服務器打交道的，前端是跟瀏覽器打交道的。似乎沒有什么問題，大家都這么認為的。當然這沒有什么錯，我們一直以來都認為僅僅是以瀏覽器作分界，把這兩部分的代碼分離出來。但是前后端分離的初衷是為了分離前后端開發人員的職責，同時解決開發模式的問題。但似乎他們的職責在以前甚至於現在都並不明確，雖然前端是跟瀏覽器打交道，但是最終瀏覽器拿到的頁面是服務器通過模板生成的一個臨時靜態頁面而已。所以，實際上后端也摻和進來了，因為他要處理模板。當然，一般傳統上的開發協作模式有兩種：
-
一種是前端先寫一個靜態頁面，寫好后，讓后端去套模板。靜態頁面可以本地開發，也無需考慮業務邏輯只需要實現View即可。不足是還需要后端套模板，這些前端代碼后端需要瀏覽一遍，以免出錯。
-
另一種協作模式是，前端直接去寫模板，這樣做的問題在於，前端編寫過程中很依賴與后端環境，如果當后端沒寫完的情況下，前端幾乎沒法干活。
顯然這兩種方式似乎都有很多問題，但至少這還是目前為止大部分公司所采用的模式。他們從物理層來區分前后端的開發，同時淡化了前端在邏輯上的色彩。由於前端所做的事情就是來實現一個頁面的靜態版本，所以，大多數公司又給前端工程師們找了點活干。你去看現在公司在招聘的時候前端工程師的要求，除了對頁面的基本制作技能外還有額外的設計職責。
到這里原本我們以為已經將前后端分離開來了，但是在模版這個尷尬的問題上，前后端的工程師們絕對吃過不少苦頭，因為在整體網站架構上，這並不是前后端的分離。
中途島(Midway Framework)
淘寶的前端團隊真的很厲害，中途島(Midway Framework)的架構在14年4月份就已經提出來了。
簡單的說，中途島架構是基於NodeJs的，因為Js是一門前后端通吃的語言，它可以作為一個橋梁搭建在原始的前后端模式中。具體的中途島思想可以參考淘寶前端團隊博客里發的博文：前后端分離的思考與實踐想象一下這個場景多么美好：前端來決定某個模板是服務端渲染還是客戶端渲染，當首屏的時候，就在nodejs里面生成HTML，不是首屏的時候，就AJAX過來在瀏覽器端渲染展示。
加入NodeJs還有很多好處，比如NodeJs的高並發特性，請求合並等。同時使用nodeJs做橋梁，前端可以自己決定獲取什么格式的數據。
SPA
現在有一個在前端領域很火的名詞SPA(Single Page Application)也就是所謂的單頁應用，在和用戶交互的時候當用戶點擊某個物件或者按鍵的時候不會跳轉到其他的頁面，會像app一樣在當前頁面進行跳轉，最典型的框架是：Angular、Backbone等。
現階段我在公司開發的移動商城就是采用Angular架構的一個SPA，切換頁面或者場景的時候並不會跳轉頁面，只是去改變鏈接上的錨點，這個錨點由ui-route監聽到，從而就由前端實現了對URL的掌控。SPA無需任何模板來控制輸出，它的展現完全靠JavaScript控制，數據是SpringMVC通過restful的api接口提供的，所以SPA所采用的前后端的分離，已經基本分的很清楚了，后台只管數據輸出和業務邏輯處理，前端負責交互邏輯和界面展示。
這樣就需要前后端在接口的方面約定好，以避免不必要的麻煩。Blueprint是一個用來編寫Api文檔的工具包，對restful API幾乎是完美兼容。