先後端分離與不分離

傳統的分離方法

在個人腦海中一提到前端和後端，基本上第一個出現的區別點就是:後端是跟數據庫跟服務器打交道的，前端是跟瀏覽器打交道的。彷佛沒有什麼問題，你們都這麼認爲的。

固然這沒有什麼錯，咱們一直以來都認爲僅僅是以瀏覽器做分界，把這兩部分的代碼分離出來。可是先後端分離的初衷是爲了分離先後端開發人員的職責，同時解決開發模式的問題。

但彷佛他們的職責在之前甚至於如今都並不明確，雖然前端是跟瀏覽器打交道，可是最終瀏覽器拿到的頁面是服務器經過模板生成的一個臨時靜態頁面而已。因此，實際上後端也摻和進來了，由於他要處理模板。

固然，通常傳統上的開發協做模式有兩種：

• 一種是前端先寫一個靜態頁面，寫好後，讓後端去套模板。靜態頁面能夠本地開發，也無需考慮業務邏輯只須要實現View便可。不足是還須要後端套模板，這些前端代碼後端須要瀏覽一遍，以避免出錯。

• 另外一種協做模式是，前端直接去寫模板，這樣作的問題在於，前端編寫過程當中很依賴與後端環境，若是當後端沒寫完的狀況下，前端幾乎無法幹活。

顯然這兩種方式彷佛都有不少問題，但至少這仍是目前爲止大部分公司所採用的模式。他們從物理層來區分先後端的開發，同時淡化了前端在邏輯上的色彩。

因爲前端所作的事情就是來實現一個頁面的靜態版本，因此，大多數公司又給前端工程師們找了點活幹。你去看如今公司在招聘的時候前端工程師的要求，除了對頁面的基本製做技能外還有額外的設計職責。

到這裏本來咱們覺得已經將先後端分離開來了，可是在模版這個尷尬的問題上，先後端的工程師們絕對吃過很多苦頭，由於在總體網站架構上，這並非先後端的分離。

中途島(Midway Framework)

簡單的說，中途島架構是基於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幾乎是完美兼容。

1、什麼是先後端分離？

先後端分離的例子就是SPA(Single-page application)，全部用到的展示數據都是後端經過異步接口(AJAX/JSONP)的方式提供的，前端只管展示。

從某種意義上來講，SPA確實作到了先後端分離，但這種方式存在兩個問題：

• WEB服務中，SPA類佔的比例不多。不少場景下還有同步/同步+異步混合的模式，SPA不能做爲一種通用的解決方案。
• 現階段的SPA開發模式，接口一般是按照展示邏輯來提供的，有時候爲了提升效率，後端會幫咱們處理一些展示邏輯，這就意味着後端仍是涉足了View層的工做，不是真正的先後端分離。

SPA式的先後端分離，是從物理層作區分（認爲只要是客戶端的就是前端，服務器端的就是後端），這種分法已經沒法知足咱們先後端分離的需求，咱們認爲從職責上劃分才能知足目前咱們的使用場景：

• 前端：負責View和Controller層。
• 後端：只負責Model層，業務處理/數據等。

2、爲何要先後端分離？

2.1 現有開發模式的適用場景

• 好比後端爲主的MVC，作一些同步展示的業務效率很高，可是遇到同步異步結合的頁面，與後端開發溝通起來就會比較麻煩。
• Ajax爲主SPA型開發模式，比較適合開發APP類型的場景，可是隻適合作APP，由於SEO等問題很差解決，對於不少類型的系統，這種開發方式也太重。

2.2 先後端職責不清

在業務邏輯複雜的系統裏，咱們最怕維護先後端混雜在一塊兒的代碼，由於沒有約束，M-V-C每一層均可能出現別的層的代碼，日積月累，徹底沒有維護性可言。
雖然先後端分離沒辦法徹底解決這種問題，可是能夠大大緩解。由於從物理層次上保證了你不可能這麼作。

2.3 開發效率問題

淘寶的Web基本上都是基於MVC框架webx，架構決定了前端只能依賴後端。
因此咱們的開發模式依然是，前端寫好靜態demo，後端翻譯成VM模版
直接基於後端環境開發也很痛苦，配置安裝使用都很麻煩。爲了解決這個問題發明了各類工具，好比VMarket，可是前端仍是要寫VM，並且依賴後端數據，效率依然不高。
另外，後端也無法擺脫對展示的強關注，從而專心於業務邏輯層的開發。

2.4 對前端發揮的侷限

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

3、怎麼作先後端分離？

• 前端：負責View和Controller層。
• 後端：負責Model層，業務處理/數據等。

試想一下，若是前端掌握了Controller，咱們能夠作url design，咱們能夠根據場景決定在服務端同步渲染，仍是根據view層數據輸出json數據，咱們還能夠根據表現層需求很容易的作Bigpipe,Comet,Socket等等，徹底是需求決定使用方式。