前后端，相煎何太急...

?

前沿：哈嘍，我是樹醬。今天分享的水文是關(guān)于前端與后端之間battle的那些事，自從前后端分離之后，這場分家?guī)砹瞬簧贉贤▎栴}，甚至產(chǎn)生battle。我們先回顧下前后端battle的前世今生

?

1.遠古時代 (web1.0 - MVC架構(gòu))

依稀記得剛大學(xué)畢業(yè)那會，電腦上安裝的第一個IDE，不是Webstorm也不是VScode，而是IntelliJ IDEA。因為開發(fā)前端項目，需要跑完整的一個JAVA程序，各種maven配置，然后在后端編寫的JSP文件基礎(chǔ)上再進行前端開發(fā)，換句話說就是“二次開發(fā)”，現(xiàn)在想想當時編譯慢的場景，歷歷在目。換句話說就是前端開發(fā)重度依賴環(huán)境

?

阿樂同學(xué)：我記得我當時就只提供HTML代碼，然后用Sublime做編輯器就好了，然后最后再整合到JSP中去

?

這就是另外一種模式，前端負責(zé)輸出demo Html，然后交給后端去套模版

只是說完全交由后端去整合，出錯率較高，遇到 Bug 解決起來也很麻煩，需要雙方協(xié)同處理。換來的更多的溝通成本。因為前后端的職責(zé)很容易糾纏不清，耦合性太強，最后還可能導(dǎo)致battle。

總結(jié)產(chǎn)生battle的點??：

• 1.前端開發(fā)重度依賴環(huán)境，導(dǎo)致每次修改文件編譯時間過長，考驗前端開發(fā)者的耐心
• 2.當應(yīng)用需要升級時，無法單獨對前端、后端獨立升級。而是對整個單體應(yīng)用整體升級
• 3.后端將前端預(yù)先開發(fā)好的html頁面，嵌入到JSP文件后，實際樣式效果偏差過大

2.鐵器時代 （web2.0 -MVVM架構(gòu)）

?

前端MVVM架構(gòu)的出現(xiàn)促進了前端開發(fā)與后端業(yè)務(wù)邏輯的分離，真正實現(xiàn)“分家”：分工協(xié)助、各司其職、拒絕捆綁。這時候就需要一個“溝通橋梁”：API ，再通過ajax調(diào)用實現(xiàn)前后端之間的協(xié)作溝通。兩者也解耦了

?

API消費者（前端）：通過接口文檔了解接口信息，聚焦點：接受數(shù)據(jù)、處理數(shù)據(jù)、處理渲染邏輯

API生產(chǎn)者（后端）：提供接口以及接口文檔 ?聚焦點：提供數(shù)據(jù)、提供API文檔

開發(fā)流程也開始轉(zhuǎn)變??：

• 后端編寫和維護接口文檔，在 API 變化時更新接口文檔
• 后端根據(jù)接口文檔進行接口開發(fā)
• 前端根據(jù)接口文檔進行開發(fā) + Mock平臺
• 開發(fā)完成后聯(lián)調(diào)和提交測試

?

啊樂同學(xué)：那前后端分離后，是后端同學(xué)先開發(fā)還是前端同學(xué)先開發(fā)？

?

從上面的開發(fā)流程我們可以看出，分家之后，接口文檔是最關(guān)鍵的溝通橋梁。根據(jù)重要先行原則，文檔就成為了首要因素，建議接口文檔先行，也就是 API-First，沒有接口文檔前端幾乎無法開工。

?

啊呆同學(xué)：對于前端同學(xué)接口聯(lián)調(diào)用postman調(diào)試，mock用Yapi或者RAP2來生產(chǎn)假數(shù)據(jù)，有沒有更好用的工具一步到位？

?

以前我也是左手一個postman，右手一個yapi，中間碼著code

你可以試試 Apifox

官方介紹：Apifox?是 API 文檔、API 調(diào)試、API Mock、API 自動化測試一體化協(xié)作平臺，定位?Postman + Swagger + Mock + JMeter

前端同學(xué)可以用Apifox來解決接口調(diào)試+數(shù)據(jù)Mock的需求

下面分享一個實戰(zhàn)頁面截圖

但新的開發(fā)流程也暴露出新的battle點

總結(jié)產(chǎn)生的battle點：

• 1.一個頁面需要請求的接口太多，前端希望后端做接口聚合，減少請求次數(shù)，后端則認為接口是根據(jù)微服務(wù)劃分職責(zé)的，無需耦合

• 2.后端提供的接口發(fā)生變更，但接口文檔卻沒有同步，或者后端提供接口缺失，前端無法正常mock等

• 3.字段不統(tǒng)一：舉個例子，手機號碼的字段，有的返回 mobilePhone，有的返回 PhoneNumber，字段不統(tǒng)一導(dǎo)致溝通成本提升

3.白銀時代 （BFF時代）

?

隨著微服務(wù)的盛行，后端數(shù)據(jù)接口被拆分獨，假設(shè)現(xiàn)在前端需要一些數(shù)據(jù)，可能都依賴幾個微服務(wù)，需要作數(shù)據(jù)聚合。而與此同時，作為離用戶最近的前端，面對各種移動設(shè)備，每個客戶端的數(shù)據(jù)類型要求不同，諸如移動端所需數(shù)據(jù)并不多，需要做數(shù)據(jù)拆解。

?

會產(chǎn)生類似下面的battle場景??：

前端同學(xué)和后端同學(xué)都各有各的道理，有沒有一種解決方案可以化解這種尷尬的場景，于是就有了BFF，BFF全稱是Backends For Frontends(服務(wù)于前端的后端)

在BFF層下面是各種后端微服務(wù)，在BFF上層則是各種前端應(yīng)用（多端應(yīng)用），向下調(diào)用后端為服務(wù)，向上給客戶端提供接口服務(wù)，后端為BFF層的前端提供的的 RPC 接口， BFF 層則直接調(diào)用服務(wù)端 RPC 接口拿到數(shù)據(jù)，按需加工數(shù)據(jù)，來完成整個BFF的閉環(huán)（以Node+GraphQL技術(shù)棧為主）

BFF的出現(xiàn)確實解決了蠻多前端后的溝通成本，彼此也友善了很多，對話就演變成這樣

• 后端：這些微服務(wù)都在這里了，你看著組合，有問題找我

• 前端：行，我看著組合

對于BFF感興趣的童鞋可以閱讀樹醬之前的?你學(xué)BFF和Serverless了嗎