先後端的分離模式

早期的web開發是不分前端後端的。
互聯網進入Web2.0時代以後，大量網站從純展現型網站演變成相似桌面軟件的Web應用，網站的前端也變的愈來愈複雜， 慢慢就造成了這樣一個單獨的職業。隨着先後端分離，前端各類框架層出不窮，前端的能力也愈來愈大，工做量跟後端相比也愈來愈平衡甚至更多。

爲何要分離？
咱們不能「爲了分離而分離」，而應該「爲了真正理解web開發、爲了更好完成需求而分離」。

先後端分離的誤區？
一、前端人員配備是否充足？
　　因爲所在公司以往項目採用傳統開發風格，即之後端MVC爲主的開發模式，前端人員僅僅提供靜態html頁面，其他工做皆由後端開發人員完成。採用先後端分離模式能夠減後臺負擔，加快研發效率，固然，前提是前端能作好的話。以往只須要提供靜態頁面的前端人員，在先後端分離模式中要負責項目的view+controller部分，即除了靜態頁面，還須要負責頁面的全部交互代碼、以及nodejs與視圖層以及後端API的交互工做，無疑增長了前端人員的學習成本，在沒有足夠知識和人才儲備的狀況下，只能讓前端人員加班加點。結果是大量前端人員離職（PS：作這麼多事，工資總得加吧！）

二、先後端職責分配？
　　不少公司認爲採用先後端分離以後，先後端只須要經過指定API進行交互便可，前端負責頁面渲染，Nodejs負責路由分配，後端提供API。忽視了大量關鍵工做，職責分配和細節處理沒有相應文檔規定，緩存機制、圖片上傳下載、數據校驗、語言國際化等等並無出具相應信息。另外，大量忽視了nodejs層的做用，僅僅把nodejs當成一個路由中轉，這一方面也是對nodejs技術的不熟悉致使的，其實nodejs能負責不少事，除了複雜業務邏輯處理和數據操做由Java 負責，大量工做徹底能夠在nodejs層處理。（PS：仍是基礎不夠致使的！）

三、後端API是否Restful風格？
　　不少公司採用了先後端分離模式後，後端API仍然採用以往的傳統風格，這是不合理的，Restful風格的API應該是先後端分離的最佳實踐。ResultFul推薦每一個URL能操做具體的資源,並且能準確描述服務器對資源的處理動做，一般服務器對資源支持get/post/put/delete/等，用來實現資源的增刪改查。先後端分離的話，這些api-url是對接的橋樑，採用resultFul接口地址含義才更清晰、見名知意。（PS：用了Spring4.x 居然還不用rest風格，說不過去啊）

四、先後端協做模式？
　　先後端分離後，不管是API接口的對接仍是測試工做，都涉及到先後端人員的溝通，不少公司採用先後端分離後，先後端協做模式配協力度底，互相等待，開發效率低下，反而不如傳統的開發模式。例如：當後端 API 沒有編寫完成時，前端沒法進行調試，這就致使了前端會被後端阻塞的狀況。其實像這種互相等待的模式須要改進， Mock Server 可能能夠解決一些問題。

如何先後端分離？
怎麼作先後端分離？大方向就是

　　後端專一於：後端控制層（Restful API） & 服務層 & 數據訪問層；
　　前端專一於：前端控制層（Nodejs） & 視圖層

　　本人認爲的先後端分離模式應該是這樣，固然這不必定正確：

　　一、項目設計階段，先後端架構負責人將項目總體進行分析，討論並肯定API風格、職責分配、開發協助模式，肯定人員配備；設計肯定後，先後端人員共同制定開發接口。

　　二、項目開發階段，先後端分離是各自分工，協同敏捷開發，後端提供Restful API，並給出詳細文檔說明，前端人員進行頁面渲染前臺的任務是發送API請(GET,PUT,POST,DELETE等)獲取數據（json，xml）後渲染頁面。

　　三、項目測試階段，API完成以前，前端人員會使用mock server進行模擬測試，後端人員採用junit進行API單元測試，不用互相等待；API完成以後，先後端再對接測試一下就能夠了，固然並非全部的接口均可以提早定義，有一些是在開發過程當中進行調整的。

　　四、項目部署階段，利用nginx 作反向代理，即Java + nodejs + nginx 方式進行。

參考
課程分享：

直播時間：2018.07.15 晚8：00~10：00pm
新前端能力課堂以前後端分離實戰或者加入企鵝羣：707871733 領取資料