前端環境部署如何配置後端接口地址

這是我參與更文挑戰的第3天，活動詳情查看： 更文挑戰

前端打包目前主要是兩個方面：打包壓縮文件以及後臺api訪問地址。固然也涉及到其餘的諸如nginx和docker部署，這些不在本文範疇。

打包命令其實很簡單

npm run build
複製代碼

後臺訪問地址

前端訪問後臺地址實際上是須要區分本地開發和服務器部署。

本地開發訪問：

本地開發是開發環境，由於本地啓動項目，開發環境能夠經過接口代理的方式解決跨域相關問題，因此咱們配置訪問地址的時候會比較簡單。

前端爲了統一處理接口訪問，會設置baseUrl，這裏的bms是應用地址前綴。

// 路徑地址：src/services/baseUrl.js

// eslint-disable-next-line import/no-mutable-exports
let baseUrl = '/api/bms';

export default baseUrl;
複製代碼

代理配置文件

// 路徑地址： config/config.js

proxy: {
  '/api/bms': {
    target: 'http://xxxxx:8000/', 
    changeOrigin: true,
    pathRewrite: { '^/api/bms': '/' },
  },
},
複製代碼

這裏的**/api/bms對應的是baseUrl.js的baseUrl。訪問地址的時候：接口訪問的是 /api/bms/interface*。經過代理會變成 http://xxxxx:8000/interface 這裏可能會問，api/bms去哪裏了。由於這行代碼：

pathRewrite: { '^/api/bms': '/' },
複製代碼

會將 /api/bms 經過代理變成 /

服務器部署地址：

前端部署：

本地環境和服務器部署的理解

由於服務器部署走的打包文件，和本地開發大不相同，沒有代理了，訪問的都是靜態文件。因此這時候咱們的代碼裏只有baseUrl.js裏的/api/bms了。這個是相對路徑，直接訪問會有問題。舉個簡單的例子：目前bms的開發環境部署地址是：
http://xxxxx:8000

那咱們服務器部署的接口訪問地址就是：http://xxxxx:8000/api/bms/interface。而後開發環境的swagger地址是：http://xxxxx:8001/interface。這個確定對應不上啊。因此就須要前端在當前這個baseUrl.js文件內部進行。

那如今咱們的文件是相對路徑，因此須要經過處理變成對應環境的絕對路徑。

這裏會有一個問題？咱們如今有三套環境，開發，測試，和生產。寫哪個呢，須要有一個變量來肯定在不一樣的環境設置正確的後臺訪問地址接口。

能夠用來判斷環境的變量BUILD_TYPE

這裏涉及到一個前端打包環境變量的概念：BUILD_TYPE。至於這個概念能夠先無論，當時咱們怎麼理解呢。理解他就能夠當成是一個變量，能夠被設置值，能夠被訪問到。咱們在baseUrl.js裏均可以訪問。咱們能夠經過判斷這個變量的類型來決定baseUrl設置成哪一個環境的api訪問絕對地址。

let baseUrl = '/api/bms';

// eslint-disable-next-line no-undef
if (BUILD_TYPE === 'build') {
  baseUrl = 'http://xxxxxx:8001/api/bms';
}

if (BUILD_TYPE === 'qa') {
  baseUrl = 'http://yyyyy:8001/api/bms';
}

if (BUILD_TYPE === 'release') {
  baseUrl = 'http://zzzzzz:8001/api/bms';
}

export default baseUrl;

複製代碼

設置環境變量BUILD_TYPE

上面講的是使用BUILD_TYPE，可是這個值在哪裏設置的呢，在咱們執行打包命令的時候。package.json文件。


從圖中能夠看到我畫圈圈的地方有三個命令，三個命令都有設置BUILD_TYPE，看到這裏應該已經知道這裏是幹什麼用的了吧，這裏就是爲了區分不一樣環境，經過不一樣的打包命令，而後設置不一樣的BUILD_TYPE，看到這裏其實前端須要處理的地方已經處理完了。可是這裏只是將命令寫好了，可是誰來觸發這個命令啊，服務器又不會向咱們還能夠本身去執行命令，並且須要人工的話，就有點太low了。

cicd命令配置【.gitlab-ci.yml文件】

開發環境
由於如今咱們的環境部署基本都是走docker + nginx + cicd命令了。因此相關的仍是要了解一下的。

開發環境配置：
開發環境就會走yarn build，其實對應就是下面的這個圖片，因此這樣就造成閉環了啊，提交代碼到develop，cicd運行下面的命令，而後會設置BUILD_TYPE爲build，而後打出來的後端訪問地址就是：上面配置的開發環境的訪問地址http://xxxxxx:8001/api/bms

測試環境 & 生產環境
原理和上面相同，惟一不一樣的是，分支代碼打測試環境tag的時候，咱們不能執行開發環境的命令了啊，要執行測試環境的命令。

後端須要注意的點：

之前碰到過的是，前期開發好好的，等到部署環境的時候就會出現跨域的問題，而後找後端的同窗，就會問，爲啥啊，不是一直用的好好的嘛。

回答：由於前期開發走的本地環境，本地作了接口代理處理，項目結構自帶的，因此不會有問題。一旦走了服務器部署，就須要後端接口作跨域處理了。由於處理跨域有不少種辦法，前端代理或者後端作跨域處理。因此有時間前端仍是後端的同窗都須要瞭解一下同源策略和跨域處理。

nginx代理處理後端服務地址問題

通過在個別項目當中發現，部署環境存在有的時候打包的接口地址沒有按照預期的訪問，可能我打的是qa環境，可是部署出來的地址仍是開發環境的地址，具體緣由應該是cicd的環境變量問題。後來咱們的項目就是用nginx統一轉發

前端build的時候不設置baseUrl，統一相對路徑/api/，經過服務器一次性設置代理轉發。好比：/api/統一訪問接口，其餘的訪問前端資源。