事出有因

昨天跟同事討論我們在用的rap2(一個集介面編寫和mock server的開源專案)和剛上線了一個easy-mock的server，到底哪個好用。

我們主要討論的點有個兩個： 介面的一致性、 編碼的無侵入性。

背景

自從前後端分離後，完成前後端的分工之後，大家就可以各司其職，並行開發。前後端的協議標準就是介面文件。前端的所有邏輯和展現全部依賴介面文件中規定的資料結構。所以介面文件就變成了開發過程的重中之重。

當然有一份文件也是不夠的，前端開發頁面邏輯除錯、測試同學測試介面、介面文件不斷的更新、介面複雜的返回情況等諸多問題，這就需要有一個Mock Server來幫忙。

更多的關於Mock內容的請大家自行Google瞭解不再贅述。

介面的一致性

介面文件，是整個開發過程中的約定和依據，所以同步更新文件也成為關鍵一環。

之前的辦法

使用markdown維護一個文件，更新之後分發給大家；或者就是放到wiki來管理，每次更新到wiki上面，供大家來閱讀。如果要Mock資料（easy-mock或者其他mock server），相關人員修改mock欄位，更新完畢。

優雅的做法

線上編輯介面，實時儲存，同步更新。例如採用Rap2（支援JSON複製，支援介面的移動複製），儲存後就是介面文件，所有人實時更新，同時Mock資料自動更新。

編碼的無侵入性

Mock 對程式碼的侵入越小，我們維護和開發的成本也越低。以 Vue-cli2.x

生成的專案為例：

在工程中的config目錄dev.env.js，配置開發環境下API資料來源地址

...
module.exports = merge(prodEnv, {
    NODE_ENV: '"development"',
    ENV_CONFIG: '"dev"',
    // BASE_API: '"dev server"',
    BASE_API: '"http://rap2.taobao.org:8080/app/mock/39"', // mock server
})

複製程式碼

這樣我們在開發過程中，用到axios，只需要根據不同環境編寫一次程式碼即可

const service = axios.create({
  baseURL
 
: process.env.NODE_ENV === 'production' ? process.env.BASE_API : '/api',
  ...
});
複製程式碼

從Mock資料切換到Dev Server的API只需要註釋一行配置檔案程式碼，無需修改專案原始碼。非常友好。

這時候我們再看easy-mock 跟rap2生成的Mock Url：

http://easy-mock.com/mock/5c08e554bd9f9c3a01c5abf6/api/info
=> host/mock/projectId/:path

http://rap2.taobao.org:8080/app/mock/45/GET/api/info 
=> host/app/mock/:repositoryId/:method/:path
複製程式碼

ps:後來發現rap2的url可以不帶method，但是就是不能使用restful API這種根據method區分的介面了。

從生成的url來看，rap2中有:method的變數，若是要無縫切換需要更多的工作。無法直接替換BASE_API。如果在程式碼裡拼接會有很大的程式碼侵入性。

所以考慮在工程層面進行優化：

在工程目錄config目錄中index.js中，可以設定代理來統一處理:method變數。在proxyTable物件中加入bypass方法，對每個通過代理的介面，處理request url成為一個合格的rap2 mock的url。

module.exports = {
  dev: {
    ...
    proxyTable: {
      '/api': {
        target: config.BASE_API.substring(1, config.BASE_API.length - 1),
        changeOrigin: true,
        pathRewrite: {
          '^/api': '/'
        },
        bypass: function (req, res, proxyOptions) {
          if (proxyOptions.target.indexOf('mock') !== -1) {
            const path = req.url.replace(proxyOptions.context, proxyOptions.context + '/' + req.method);
            // path => /api/GET/path
            req.url = path;
          }
        }
      }
    },
複製程式碼

這樣就能無侵入性的使用rap2了。

結論

從介面文件的一致性和編碼的無侵入性來看，rap2可能更優一點，但是rap2畢竟是一個年輕的開源專案，很多機制並不完善。從去年年初使用rap2，最近升級到新版本資料庫表結構還要做對映調整，適合喜歡折騰的人。這樣easy-mock的穩定性優勢就值得考慮。

在我看來，未來的Mock Server不單單只是一個Mock，肯定是集 介面編寫 + 自動Mock於一身的，還有一些類似介面欄位校驗的輔助功能。

個人還是很看好rap2的，畢竟從rap1重構的專案，有一定的使用背景，重構應該能出更好的開源專案。

再次感謝開源專案對開發者帶來的便利。

Mock.js : mockjs.com/

easymock: easymock.org/

rap2 : rap2.taobao.org/