一條命令解決介面Mock

fwon發表於2018-10-15
Mock

背景

在前端或客戶端開發中，經常需要依賴後端同學開發的API。為了能夠前後端並行開發，前端通常會採用Mock資料的方法，通過模擬api假資料進行頁面渲染。等到後端API開發完畢再接入真實API進行除錯。

API資料Mock的方法有很多，常用的有以下幾種：

前端打包工具安裝Mock外掛

比如Grunt, Gulp, Webpack等等都有相應的mock外掛，開發者需要根據不同的專案型別來做配置。其原理是啟動一個本地伺服器實現介面請求。由於是模擬網路請求，所以有時還需要根據需求對一些打包指令碼進行修改。該方法的缺點是針對不同的工具需要有不同的方案，有一定的安裝和適配成本，並且只針對使用打包工具的專案。

外部Mock服務平臺

業界有一些Mock的解決方案，提供一個第三方平臺，開發者在平臺上配置api介面，然後直接呼叫平臺介面進行除錯。比較出名的如 easy-mock。

這種方法的優點是無任何外掛依賴，所有專案都可以直接訪問使用，無需安裝，所以對客戶端也是通用的。但是帶來另外一個問題是資料的洩露，一些隱私度比較高的專案可能會覺得把模擬資料放到其他平臺上也是不安全的。當然easy-mock也考慮到這個問題，開源並支援使用者直接部署專案到公司內網。但這個需要主機，資料庫等資源的支援，落實難度較大。

寫死資料

第三種是比較直接的，就是在前端寫死資料，介面不發出請求而是直接返回。這種方法對於一些小的活動專案也許是不錯的選擇。但是構造的資料模式有限，也無法模擬真實的網路環境

在以前的開發中使用的基本是這三類方法，但是這些方法都有上述提到的明顯的侷限性。

另一種方式

為了避免以上方案中的缺點，本文介紹另外一種mock的思路

對於Mock資料，我們希望它在專案中的存在只是一個資料夾，裡面定義了每個介面的返回資料。開發者不需要配置專案外掛，每個專案都可以簡單的通過一個命令啟動mock服務，並監聽這個目錄。這個Mock服務需要具備以下功能：

  1. 模擬介面請求，靈活配置返回資料
  2. 在開發人員間共享模擬資料，而不是隻存在本地，也不是放在外網
  3. 不要繁瑣的安裝配置，最好一個命令開啟即用
  4. 對於所有型別的前端專案都是通用的
  5. 提供一些複雜需求的擴充功能

基於以上思路開發了一個工具 l-mock

實現資料mock只需三步：
1.全域性安裝

npm i l-mock -g

2.初始化mock目錄, init命令在project根目錄下生成mock目錄，並放置demo介面

cd path/to/project
lmock init

3.執行, 進入生成的mock目錄，執行start命令，直接訪問localhost:3000/a 則可看到/a介面返回

cd mock
lmock start

第一次初始化後，後面的開發只需要在mock目錄中執行lmock start就可以開啟介面模擬。

對於有package.json的前端專案，可以直接配置在npm命令中，往後就執行 npm run mock

"scripts": {
  "mock": "cd mock && lmock start",
}

怎麼來編寫一個模擬介面呢？舉一個例子:

path/to/project/mock/a.js 模擬了一個get請求

module.exports = {
  url: '/a',
  method: 'get',
  result: {
    'status|1': ["no_login", "OK", "error", "not_registered", "account_reviewing"],
    'msg': '@csentence()',
    'data': {
      a: 2
    }
  }
}

以上js返回的json內容如下

roadmap.path

params description
url 配置API地址, 支援正則匹配模式
method 配置請求方法，支援RESTFUL
result 定義返回內容

result 可以直接返回json內容，通過Mockjs,可以生成動態的資料內容，比如上面的@csnetence()會隨機生成一個段落的文字

Mockjs的語法很多，可以參考其文件。

該工具還有一些擴充功能，需要用到複雜介面邏輯的，可以在result返回方法中配置。

詳細的使用方法可以參考工具文件 l-mock

如果你的專案中正好需要用到資料Mock，不妨試一試。

相關文章