前言
大資料部發展到一定的階段，無論是内部體系的完善，還是服務能力對外的暴露，對web端互動能力都有極大的需求，是以對web研發的訴求其實也是非常大的。
現在不少web後端工程師還是基于傳統的開發模式，通過服務端渲染，把服務端的代碼散布在每個div塊裡，但最終又不可避免的還是需要引入js進行互動，但采用的卻是最傳統的刀耕火種方式通過<javascript> 引入js，導緻js的開發難度也非常大，沒有包管理，沒有版本管理，元件化，還處于十年前前端階段，更别說給js做單元測試，end2end測試了。是以其實效率是極低的。
前後端分離方式
我們在追求前後端分離的時候，一般而言有三種模式：
- 前端需要用一些前端架構如vue,react以及服務架構（nodejs），然後後端提供一個或者多個API服務。
- 把前端架構直接釋出到靜态伺服器上，然後前端直接和一個或者多個後端API服務互動。
- 把前端架構直接釋出到對應的服務上，成為對應服務的一部分。
對于一個小而不精的團隊，第一種模式會極大的加大協作成本，以及重複開發成本。有的時候這就好比以前後端強硬分層，Service層和DAO層其實完全一樣的的代碼。第二種模式則需要涉及到跨域或者需要後端再提供一個Proxy服務（網關)。第三種則完全通過一個web工程師就可以cover住，目前看來應該是人效比比較高的一種模式。
為什麼Web後端工程師要擁抱前端
為了更好的感受前端的技術，我開發了一個示例項目，進而讓自己更真實的感受第三種模式的優點和缺點。
前面我們提到，采用傳統web開發的模式，其實是一種刀耕火種方式，并且難以規避對js的使用，很多情況下js的使用會非常的重。RubyOnRails早年對此也做了很多工作，使得其成為一個很成功的純後端架構,但後端終究是難以取代前端的。
采用傳統web開發的模式最大的問題是：
- 沒有很好的依賴管理工具。JavaScript世界有海量的庫，沒有很好的引入和管理，這就導緻很難從中收益。
- 代碼是不好管理的，和後端完全耦合在一起。
- 測試是困難的，因為div裡内嵌了大量服務端代碼，需要服務端支援。
- 後端是不清晰的，如果純粹API會更好的被組織和管理。
- 最最主要的是，前端架構使得我們隻要專心操作資料，而不是如何操作dom結構。純前端的開發模式可以讓這個優勢更加明顯。
事實上，經過我實踐，把自己的一個web項目拆分成一個前端，一個後端API,然後單獨完成，既沒有協作成本，也能讓自己充分享受兩邊的技術紅利。當然，唯一的缺點是，Web後端工程師又要多學點東西了。