對先後端分離研究了一段時間,恰逢公司有一個大項目決定嘗試使用先後端分離模式進行,便參與其中。該項目從2016年初立項至今,平平穩穩得度過,但也涌現出愈來愈多的問題,絕對不是說先後端分離模式很差,而是不少公司在嘗試先後端分離的時候沒有作好充分得準備。html
網上對先後端分離介紹的文章已經家常便飯,接下來本人用一點粗淺的言語也談談這塊,獻醜了。前端
若是隻問「先後端分離的意義大麼?」這是廢話,由於從軟件架構的角度 Web 的先後端從一開始不就一直是分離的麼,並且 browser、server 可能將永遠分離下去。vue
爲了瞭解這個問題,咱們有必要先了解一下 Web的研發模式演變,關於這個題材,下面這篇博文說得不錯,這邊就不作搬運工了。node
https://github.com/lifesinger/blog/issues/184nginx
咱們不能「爲了分離而分離」,而應該「爲了真正理解web開發、爲了更好完成需求而分離」。git
一、前端人員配備是否充足?github
因爲所在公司以往項目採用傳統開發風格,即之後端MVC爲主的開發模式,前端人員僅僅提供靜態html頁面,其他工做皆由後端開發人員完成。採用先後端分離模式能夠減後臺負擔,加快研發效率,固然,前提是前端能作好的話。以往只須要提供靜態頁面的前端人員,在先後端分離模式中要負責項目的view+controller部分,即除了靜態頁面,還須要負責頁面的全部交互代碼、以及nodejs與視圖層以及後端API的交互工做,無疑增長了前端人員的學習成本,在沒有足夠知識和人才儲備的狀況下,只能讓前端人員加班加點。結果是大量前端人員離職(PS:作這麼多事,工資總得加吧!)web
不少公司認爲採用先後端分離以後,先後端只須要經過指定API進行交互便可,前端負責頁面渲染,Nodejs負責路由分配,後端提供API。忽視了大量關鍵工做,職責分配和細節處理沒有相應文檔規定,緩存機制、圖片上傳下載、數據校驗、語言國際化等等並無出具相應信息。另外,大量忽視了nodejs層的做用,僅僅把nodejs當成一個路由中轉,這一方面也是對nodejs技術的不熟悉致使的,其實nodejs能負責不少事,除了複雜業務邏輯處理和數據操做由Java 負責,大量工做徹底能夠在nodejs層處理。(PS:仍是基礎不夠致使的!)json
不少公司採用了先後端分離模式後,後端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 方式進行。
走過的「中轉站」可能愈來愈多,可是不要漸行漸遠纔是。