前後端分離的演變

記得12年從事工作的時候公司還沒有專門的前端人員，一般我們都是前後端都會，畢竟那時候H5才剛剛起來微軟的XP還在流行使用（預設系統自帶IE6），IE的市場份額還是蠻大的。做的產品也沒有很炫酷的特效（如果有也會選擇使用flex），那時候Flash 是超級火的......扯得有點遠了。
在開發的時候也是一邊API介面服務，一邊開發頁面，釋出也是一個釋出包搞定。前端一般只是負責切圖工作，就是將UI設計師的設計圖佈局成靜態頁面，前端是不參與互動邏輯和業務開發的，前端也是當時統一的吐槽物件。當時淘寶的Web架構比較流行基本上都是基於MVC框架webx，所以前端寫好靜態html 然後後端開發人員翻譯成vm模板...
 
..
這樣就導致了前後端工作的分配不均，開發效率慢，程式碼維護量也大。為了解決痛點 慢慢開始前後端分離的架構流行開來 很好的解決了前後端分工不均問題，將更多的互動邏輯分配給前端來處理，而後端則可以專注於其本職工作。例如後臺開發可以有跟多的時間進行後臺許可權控制以及複雜的運算工作，前後臺解耦 ，兩者同時開始推進專案進度，增加開發效率。

如何進行前後端分離

最開始的時候是SPA式的前後端分離法，單純的從物理層做區分（認為只要是客戶端的就是前端，伺服器端的就是後端），這種分法不能滿足前後端分離的需求，認為從技術職責上劃分才能滿足目前我們的使用場景，作者在工作中使用過兩種方案：

第一種：
前端：負責View和Controller層。
後端：只負責Model層，業務處理/資料等。
 

優點：可以做url design，我們可以根據場景決定在服務端同步渲染，還是根據view層資料輸出json資料，我們還可以根據表現層需求很容易的做Bigpipe,Comet,Socket等等，完全是需求決定使用方式。
缺點：需要前端來寫Controller，以Java語言開發為例，需要前端學會Java開發，這樣在處理複雜的業務邏輯的產品裡雙方都有Java 程式碼方面的重疊。

第二種：
前端：負責View層。
後端：負責和Controller、Model層和業務處理/資料等。

優點：前端不需要學習後臺開發語言，只需要呼叫API服務就好，前後端程式碼分別統一管理起來 形成自己的對接規範。這樣前端可以和不同的後臺語言做對接服務。

RESTful Api和Json搭建前後臺互動

備註：現在公司使用的RESTful 架構，後臺提供一組設計原則和約束條件。

RESTful 主要用於客戶端和伺服器互動類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現快取等機制。

RESTful Api和Json 技術的使用讓前後端互動日益便利
前後端分離以後就存在資料互動的問題,如何快速、簡潔、有效和統一的在前後臺進行資訊的互動,成為分離以後必須考慮的問題。
幸運的是, RESTful思想和Json資料標準的出現,使得這種互動日益便利,在前端,我們耳熟能詳的JS技術和框架對RESTful和Json的支援可以說已經水到渠成. 至於後端,不管什麼語言,什麼平臺都有非常成熟的方案.
前後端的不同發展趨勢使得前後端分離需求日益明顯.

漸進式框架Vue.js

Vue  是一套用於構建使用者介面的漸進式框架。與其它大型框架不同的是，Vue 被設計為可以自底向上逐層應用。Vue 的核心庫只關注檢視層，不僅易於上手，還便於與第三方庫或既有專案整合。另一方面，當與現代化的工具鏈以及各種支援類庫結合使用時，Vue 也完全能夠為複雜的單頁應用提供驅動。

備註：先介紹到這裡，有不同的想法可以下方留言一起討論。

**總結：眾所周知，Web開發自出現以來一直存在效能，表現和體驗的先天不足，但時至今日，事實已經並非如此，一些看上去甚至比桌面程式更炫的應用和網站橫空出世，客戶也被吊足了胃口。Web開發桌面化已經是無法阻擋的潮流，而前端開發的需求應該會向更加註重介面表現，速度流暢，使用者體驗的方向發展，而且要求只會越來越高。
而在後端穩定、效能、安全、儲存和業務等核心問題依然是主流，所以前後端的需求必將日益分化，注重表現和注重內在的前後端開發人員必將需要適合自己的舞臺。**

更多精彩內容請關注“IT實戰聯盟”公眾號哦~~~