淺談先後端分離技術

文章來自簡書：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幾乎是完美兼容。