前沿：哈嘍，我是樹醬。今天分享的水文是關於前端與後端之間battle的那些事，自從前後端分離之後，這場分家帶來了不少溝通問題，甚至產生battle。我們先回顧下前後端battle的前世今生
1.遠古時代 (web1.0 - MVC架構)
依稀記得剛大學畢業那會，電腦上安裝的第一個IDE，不是Webstorm也不是VScode，而是IntelliJ IDEA。因為開發前端專案，需要跑完整的一個JAVA程式，各種maven配置，然後在後端編寫的JSP檔案基礎上再進行前端開發，換句話說就是“二次開發”，現在想想當時編譯慢的場景，歷歷在目。換句話說就是前端開發重度依賴環境
阿樂同學：我記得我當時就只提供HTML程式碼，然後用Sublime做編輯器就好了，然後最後再整合到JSP中去
這就是另外一種模式，前端負責輸出demo Html，然後交給後端去套模版
只是說完全交由後端去整合，出錯率較高，遇到 Bug 解決起來也很麻煩，需要雙方協同處理。換來的更多的溝通成本。因為前後端的職責很容易糾纏不清，耦合性太強，最後還可能導致battle。
總結產生battle的點?：
- 1.前端開發重度依賴環境，導致每次修改檔案編譯時間過長，考驗前端開發者的耐心
- 2.當應用需要升級時，無法單獨對前端、後端獨立升級。而是對整個單體應用整體升級
- 3.後端將前端預先開發好的html頁面，嵌入到JSP檔案後，實際樣式效果偏差過大
2.鐵器時代 （web2.0 -MVVM架構）
前端MVVM架構的出現促進了前端開發與後端業務邏輯的分離，真正實現“分家”：分工協助、各司其職、拒絕捆綁。
這時候就需要一個“溝通橋樑”：API ，再通過ajax呼叫實現前後端之間的協作溝通。兩者也解耦了
API消費者（前端）：通過介面文件瞭解介面資訊，聚焦點：接受資料、處理資料、處理渲染邏輯
API生產者（後端）：提供介面以及介面文件 聚焦點：提供資料、提供API文件
開發流程也開始轉變?：
- 後端編寫和維護介面文件，在 API 變化時更新介面文件
- 後端根據介面文件進行介面開發
- 前端根據介面文件進行開發 + Mock平臺
- 開發完成後聯調和提交測試
啊樂同學：那前後端分離後，是後端同學先開發還是前端同學先開發？
從上面的開發流程我們可以看出，分家之後，介面文件是最關鍵的溝通橋樑。根據重要先行原則，文件就成為了首要因素，建議介面文件先行，也就是 API-First，沒有介面文件前端幾乎無法開工。
啊呆同學：對於前端同學介面聯呼叫postman除錯，mock用Yapi或者RAP2來生產假資料，有沒有更好用的工具一步到位？
以前我也是左手一個postman，右手一個yapi，中間碼著code
你可以試試 Apifox
官方介紹：Apifox 是 API 文件、API 除錯、API Mock、API 自動化測試一體化協作平臺，定位 Postman + Swagger + Mock + JMeter
前端同學可以用Apifox來解決介面除錯+資料Mock的需求
下面分享一個實戰頁面截圖
但新的開發流程也暴露出新的battle點
總結產生的battle點：
1.一個頁面需要請求的介面太多，前端希望後端做介面聚合，減少請求次數，後端則認為介面是根據微服務劃分職責的，無需耦合
2.後端提供的介面發生變更，但介面文件卻沒有同步，或者後端提供介面缺失，前端無法正常mock等
3.欄位不統一：舉個例子，手機號碼的欄位，有的返回 mobilePhone，有的返回 PhoneNumber，欄位不統一導致溝通成本提升
3.白銀時代 （BFF時代）
隨著微服務的盛行，後端資料介面被拆分獨，假設現在前端需要一些資料，可能都依賴幾個微服務，需要作資料聚合。而與此同時，作為離使用者最近的前端，面對各種移動裝置，每個客戶端的資料型別要求不同，諸如移動端所需資料並不多，需要做資料拆解。
會產生類似下面的battle場景?：
前端同學和後端同學都各有各的道理，有沒有一種解決方案可以化解這種尷尬的場景，於是就有了BFF，BFF全稱是Backends For Frontends(服務於前端的後端)
在BFF層下面是各種後端微服務，在BFF上層則是各種前端應用（多端應用），向下呼叫後端為服務，向上給客戶端提供介面服務，後端為BFF層的前端提供的的 RPC 介面， BFF 層則直接呼叫服務端 RPC 介面拿到資料，按需加工資料，來完成整個BFF的閉環（以Node+GraphQL技術棧為主）
BFF的出現確實解決了蠻多前端後的溝通成本，彼此也友善了很多，對話就演變成這樣
後端：這些微服務都在這裡了，你看著組合，有問題找我
前端：行，我看著組合
對於BFF感興趣的童鞋可以閱讀樹醬之前的 你學BFF和Serverless了嗎?
本作品採用《CC 協議》，轉載必須註明作者和本文連結