關於先後端分離與不分離

前端開發者(Frontend Developer)所作的就是開發產品的前端，所謂的 應用產品的前端就是用戶看到，接觸到和體驗到的，他們主要作靜態用戶界面加上一些動態效果，不涉及數據邏輯，前端考慮到的是用戶體驗，然後端開發者（Backend Developer）就不同了，他們是在後臺工做的，控制着前端的內容，主要負責程序設計架構思想，管理數據庫等。

      先後端分離和微服務同樣，漸漸地影響了新的大型系統的架構。微服務和先後端分離要解決是相似的問題，解耦——能夠解耦複雜的業務邏輯，解耦架構。可要是說相像吧，消息隊伍和先後端便類似一些，經過傳遞數據的形式來解耦組件。

    先後端分離意味着，先後端之間使用 JSON 來交流，兩個開發團隊之間使用 API 做爲契約進行交互。今後，後臺選用的技術棧不影響前臺。當後臺開發人員選擇 Java 的時候，我能夠不用 JSP 來編寫前端頁面，繼續使用個人 React 又或者 Angular。而我使用 React 時，也不影響後臺使用某一個框架。

    過去，據說 TDD (Test-driven development，測試驅動開發) 能夠改善代碼的質量，咱們便實施了 TDD；接着，據說 BDD (Behavior-driven development，行爲驅動開發) 能夠交付符合業務需求的軟件，咱們便實施了 BDD；後來，據說 DDD (Domain-driven design，領域驅動設計) 能夠分離業務代碼與基礎代碼，咱們便實施了 DDD。今天，據說了先後端分離很流行，因而咱們就實施了先後端分離——這就是傳說中的 HDD（Hype-driven Development，熱鬧驅動開發）。

      頁面交互是否複雜 ？是簡單的提供頁面給用戶瀏覽？或者想要支持複雜的用戶操做？是否須要搜索引擎優化？若是須要的話，那麼從一開始咱們就須要考慮後端渲染。能提高開發效率嗎？若是不能有效的提高開發效率，爲何要做死呢？是否會提供 API 給 APP？若是咱們已經有一個 API 提供給 APP，那麼要作這件事就很容易了。若是將來會有的話，那麼咱們更應該嘗試去分離。前端的修改是否是很是頻繁？若是不須要常常修改的話，那麼這種優化便沒有優點。

固然了，若是老闆說，咱們須要先後端分離，那就作唄！不少時候，一些技術決策都會因爲戰略緣由，而發生一些有意思的變化。

先後端分離將遇到的那些挑戰

當咱們決定須要先後端分離時，咱們仍然還須要面對一系列的問題：

是否足夠的安全？若是咱們設計出來的架構不夠安全，那麼這一系列的操做都是白搭。咱們怎麼去存儲用戶數據，使用 LocalStorage 的話，還要考慮加密。採用哪一種認證方式來讓用戶登陸，並保存相應的狀態？是否有足夠的技術來支撐先後端分離？有沒有能力建立出符合 RESTful 風格的 API？是否有能力維護 API 接口？當前端或者後臺須要修改接口時，是否能輕鬆地修改。先後端協做的成本高不高？前端和後臺兩個團隊是否是很容易合做？是否是能夠輕鬆地進行聯調？先後端職責是否能明確？即：後臺提供數據，前端負責顯示。是否創建了前端的錯誤追蹤機制？可否幫助咱們快速地定位出問題。

當咱們在不一樣的項目組上嘗試時，就會發現主要的挑戰是溝通上的挑戰，而非技術上的侷限。

先後端分離的核心：後臺提供數據，前端負責顯示

我曾經有過使用 PHP 和 Java 開發後臺代碼的經歷，仍然也主要是集中在前端領域。在這樣的傳統架構裏，編寫前端頁面可不是一件容易的事。後臺只會傳給前端一個 ModelAndView，而後前端就要撲哧撲哧地去豐富業務邏輯。

傳統的 MVC 架構裏，由於某些緣由有至關多的業務邏輯，會被放置到 View 層，也就是模板層裏。換句話來講，就是這些邏輯都會被放到前端。咱們看到的可能就不是各類if、else還有簡單的equal判斷，還會包含一些複雜的業務邏輯，好比說對某些產品進行特殊的處理。

若是這個時候，咱們還須要作各類頁面交互，如填寫表單、Popup、動態數據等等，就再也不是簡單的和模板引擎打交道了。咱們須要編寫大量的 JavaScript 代碼，由於業務的不斷增長，僅使用 jQuery 沒法管理如此複雜的代碼。

     

輸出邏輯：數據顯示

而僅僅只是由於邏輯複雜的前端代碼，沒法影響大部分團隊進行先後端分離——由於它沒有業務價值。其實是先有了單頁面應用，纔會出現先後端分離。單頁面應用可讓用戶不須要下載 APP，就能夠擁有類似的體現。而且與早期的移動網頁相比，擁有更好的體驗。

爲了達到這樣的目的，後臺彷佛返回對應的 Model 便可，稍微修改一下 Controller 的邏輯，而後返回這些數據。

與此同時，後臺應該按時間來對博客進行排序。前端只須要遍歷這個數組，隨後取出相應的值顯示便可，不須要作任何的邏輯處理。

遺憾的是，在真正的項目中開發的時候，並不能達到這麼完美的狀態。特別是，爲了提升用戶體驗時，咱們可能就會將數據存儲在本地，隨後直接操做這些數據，對其進行排序，篩選等等的操做。除此，還有諸如表格、圖表等等的高級樣式，也須要處理這些數據。

而當用戶須要提交數據的時候，這些邏輯就會落到前端上。

不可避免的前端邏輯：表單

若是一個前端應用只顯示數據的話，那麼這個應用就沒有充足的理由，作成一個單頁面應用——單頁面應用是爲了更好的交互而存在的。當咱們註冊、登陸、購買東西時，就須要開始與表單進行處理。

合理的表單驗證模式應該是：雙向驗證。

前端在用戶輸入的過程當中就須要實時地檢查，是否帶有特殊符號、值是不是在容許的範圍內、是否是符合相應的規範等等。而不是等用戶填寫完內容並提交後，再由服務端來告訴用戶說，「你的用戶名不符合規範」。

服務在收到前端收到的數據後，無論前端有沒有進行驗證，都應該按後臺的邏輯進行驗證。

因而乎在這個時候，這些邏輯就被無可避免地放到前臺裏了。