最近我的朋友王小閏進入一家新的公司，正好公司專案採用的是前後端分離架構，技術棧是王小閏非常熟悉的vue全家桶，後端用的是Java語言。
在前後端開發人員碰面之後，協商確定好了前端需要的資料介面（扯那麼多，其實也就是關於json資料的欄位的定義），然後前後端程式猿就嗨皮地併線開發去了。
前後端聯調前夕
我的朋友王小閏他們這家公司做本地旅遊專案的，安排到他手上的活兒是該旅遊專案的webapp工程。
專案動工伊始，一切都得從頭來做。在公司沒日沒夜的開發了一天之後，王小閏在沒有藉助vue-cli官方提供的腳手架工具下，徒手從零開始，搭建了一套基於公司特定要求的vue專案的工程架構目錄。（關於如何從零開始搭建vue專案的腳手架工程，後面我會單獨寫一個系列）。
前端專案環境搭建好之後，就正式進入了專案首頁的業務編碼工作。王小閏又沒日沒夜的敲了一天程式碼之後，首頁header區域、輪播圖以及導航圖示的頁面佈局和邏輯開發都實現了，此時他想呼叫後端資料測試下流程，但是後端程式猿還沒有將該資料的介面開發出來，沒辦法，我的朋友王小閏此時只能在本地模擬點假資料，逼格高點的說法叫mock資料。
搗鼓半天，首頁的mock資料終於弄好了，如下圖所示：
但是現在有一個問題讓王小閏很困惑，他的axios寫的url路徑是與後端程式猿商量好的絕對路徑（域名+請求路徑+請求引數），因為這是以後真正的請求路徑，所以我朋友王小閏又不想先寫本地相對路徑，後期再來修改，萬一後端程式猿開發的慢了，鬼知道到時候有多少介面需要修改，所以他就迷茫不知所措了。
其實，仔細看看，這就是前後端分離中的mock資料和介面聯調的問題。要想弄懂其中緣由，下面讓我們分幾點來聊聊。
什麼是前後端介面聯調
之前開發寫程式碼的時候，所有的ajax資料都不是後端返回的真實資料，而是我們自己通過介面mock模擬的假資料，當前端的程式碼編寫完畢，後端的介面也已經寫好之後，我們就需要把mock資料幹掉，嘗試使用後端提供的資料，進行前後端的一個除錯，這個過程我們就把它稱之為前後端的介面聯調。
為什麼要聯調
本地的mock資料是王小閏自己寫的，肯定符合前端需求，但是後端介面首先需要測試通不通，還需要測試資料格式對不對，還有後端有沒有填寫足夠的資料，比如寫列表頁，前端想分頁，如果後端就寫了兩條測試資料，你咋整？
所以，王小閏需要根據後端對介面的調整，不斷地來回切換url，這樣豈不是還在受後端的影響，還談什麼毛線的前後端分離，名存實亡嘛！
如何實現前後端介面聯調
首先，我們已經知道，目前的前後端分離的架構應用分為兩種情況：
-
- 前後端完全分離，前後端分別擁有自己的域名和伺服器。
-
- 前後端開發分離，但是部署時是一個域名和一臺伺服器。
雖然架構可以採用前後端分離，但是部署有可能就不一樣了，這和專案的大小，公司的情況等等都有關係了，一個百八十人用的小系統，還得兩臺伺服器兩個域名，你不覺著浪費嗎？
兩種不同的部署情況直接導致了前期在設計聯調方案的時候就不同了。
如果你們公司的專案在部署時是兩臺伺服器對應兩個域名，恭喜你，這是最nice的方案，也是聯調最舒服的方式。
但是，我朋友王小閏呆的這家公司是一家剛起步的小公司，肯定是怎麼節省成本怎麼來，問過後端，才知道他們公司是屬於第二種情況，也就是開發時前後端分離，部署時是一個域名和一臺伺服器。知道這個之後，他就明白接下來該怎麼操作了。
王小閏之前在專案根目錄static資料夾下新建了一個mock資料夾，裡面寫了一些json檔案，當我們做聯調的時候，這些mock資料就沒用了，我們要把mock資料切換成後端提供給我們的真實的資料。
當我的朋友王小閏把static資料夾下的mock資料刪除之後，在執行專案，發現報錯了，瀏覽器告訴他，你訪問的mock下面的index.json檔案找不到404。
我們平時本地前端開發環境dev地址大多是 localhost:8080，而後臺伺服器的訪問地址就有很多種情況了，比如 後端程式猿本地IP（127.0.0.1:8889），或者外網域名，當前端與後臺進行資料互動時，自然就出現跨域問題（後臺服務沒做處理情況下）。axios不支援jsonp, 所以我們就要使用http-proxy-middleware中介軟體做代理。
現在通過在前端修改 vue-cli 的配置可解決： vue-cli中的 config/index.js 下配置 dev選項的 {proxyTable}:
proxyTable: {
'/api': {
target: '127.0.0.1:8889', // 真實請求的地址
changeOrigin: true, // 是否跨域
}
}
複製程式碼如果你想在公司的vue專案中實現前後端聯調，不需要再使用類似於fiddler charles的抓包代理工具了，你只需要使用proxyTable這個配置項，把你需要請求的後端的伺服器地址寫在target值裡就OK了。
解決完跨域問題後，接下來王小閏該想想怎麼在一臺伺服器一個域名下進行聯調的問題了。比較常見的做法是前端在本地修改，本地檢視，測試好了以後上傳到伺服器，看看線上環境可不可以，OK的話一切都好；不行就本地接著改，然後在上傳。
聯調完之後，如何將前端打包的專案檔案發給後端，這裡也需要注意兩點：
（1）css、js和圖片等靜態檔案
這時候的靜態檔案在開發階段不需要任何考慮，按照你喜歡的相對路徑或者相對於專案的根路徑的形式寫就行了，因為早晚還得交給後端。但是，需要注意：
如果你採用 相對專案根路徑的書寫方式來寫你的靜態檔案路徑 時，一定要先和後端商量好，將來專案部署的時候他會把你的前端整個專案放在哪裡？如果不是根目錄下，你就掛了。比如：你的reset.css的路徑是 /exports/styles/common/reset.css ，後端把你前端專案放在了根目錄下的 frontEnd 資料夾下， reset.css 檔案就報404了。
如果後端採用的java，你需要特別注意的是， tomcat的根目錄 並不是 webapps 檔案，而後端專案預設是部署在 webapps/ROOT 檔案下的，所以你如果使用了相對專案根路徑的書寫方式來寫你的靜態檔案路徑時，對不起又是404了。
（2）ajax後端資料
因為現在唯一的一臺伺服器還是在後端程式猿那裡，所以此時你還是可以寫絕對路徑（域名+請求路徑），利用hosts檔案來改變域名對映實現聯調。
閏土有話說
看這篇文章的童鞋，不管你是在大公司還是在小公司，都需要知道，並不是說你將dist檔案打包發給後端就完事了，就不需要了解leader後面操作的點選部署、合併分支的事兒了。
基礎命令、拉取分支、構建編譯包、copy生產包到伺服器、備份資料、啟動指令碼、灰度釋出、等等流程其實都是很有必要了解的。
要不然最開始沒有這些基礎設施、基礎元件，誰來搭建+執行呢，畢竟還是需要第一批吃螃蟹的人.
即使大公司，也有小團隊的，有的小團隊不一定遵循大公司那一套自動化部署教程，也有自己玩自己的輪子+工具。
就算是大公司， 如果基礎架構組的工具做好了，但是沒有總監以上的大佬面向公司推廣， 這些基礎設施不一定能面向公司內部使用。
基礎設施、基礎元件能夠面向公司內部大量使用，離不開公司高層領導的支撐、當然也有基礎設施團隊的辛苦開發、還需要有使用基礎元件的機遇和業務場景。
總結：就像我之前文章裡講過的，當你處在前後端分離的大浪潮下，做前端的要將眼光放在整個專案上，統籌全域性，不要偏安一隅，待在前端的小角落裡獨自玩耍。
一句話，格局要放大，步子要邁開，然後才是低頭前行。
更多文章我會第一時間更新在公眾號<閏土大叔>裡面，歡迎關注~
