前端架構之路（2） - 本地化接口模擬、先後端並行開發

本地化接口模擬、先後端並行開發

1. 爲何須要 「本地化接口模擬、先後端並行開發」

在先後端分離以前，先後端的數據交流以及頁面渲染使用後端的模板（如 java > jsp、php > smarty）是很常見的，因此前端對頁面的開發與調試老是依賴後端程序，而不能本地運行，這就致使前端開發很耗時，而且毫無心義。先後端分離以後，前端可以在本地運行服務程序、開發、調試，這讓前端開發人員從與後端耦合開發的過程當中解脫出來，更高效快捷的開發 web 前端程序。基於此，咱們便有了「本地化接口模擬」的需求。

2. 本地化接口模擬

這就是說咱們要在本地模擬一個與服務器差很少的環境，可以提供數據所需的接口，進行錯誤模擬處理等等。

通常來講，本地數據模擬的解決方案有兩種思路：

1. 同等模擬服務器環境，就是依據文檔，徹底按照服務器的接口配置搭建本地的接口服務；
2. 多環境配置&切換，就是從代碼的層面配置多個環境（如 線上環境，本地環境），根據是在線上仍是在本地切換不一樣的環境。

2.1 同等模擬服務器環境

這種方式基本上不須要在代碼層面作更改，由於本地接口與服務器接口基本上一致，包括接口名稱，請求方法，請求參數，響應數據。

這種思路的解決方案不少，比較典型的有：

RAML(RESTful API Modeling Language 即 RESTful API 建模語言)：

基於 YAML，幫助設計 RESTful API 和鼓勵對API的發掘和重用，解析並自動生成對應的客戶端調用代碼、服務端代碼 結構, API說明文檔。

這個工具強能很強大，本地化接口模擬只是其中的一個功能。

Swagger：

基於 JSON 進行文檔定義的一個規範和完整的框架，用於生成、描述、調用和可視化 RESTful 風格的 Web 服務。

也是一個功能很強大的工具，本地化接口模擬也只是其中的一個功能。與RAML相比，RAML解決的問題是設計階段的問題，而Swagger則是側重解決現有API的文檔問題，它們最大的不一樣是RAML須要單獨維護一套文檔，而Swagger則是經過一套反射機制從代碼中生成文檔，而且藉助ajax能夠直接在文檔中對API進行交互。

API Blueprint：

基於 Markdown 的一套 API 描述標準，使用工具能夠把標記文稿轉換成漂亮的接口文檔，並提供本地化接口模擬功能。

由於是基於 Markdown，因此使用門檻比前二者低了不少，但功能不及前二者強大。

2.2 多環境配置&切換

這種方式是在代碼的層面配置多個環境（如 線上環境，本地環境），根據是在線上仍是在本地切換不一樣的環境。

好比，開發的時候切換到本地環境，線上運行的時候切換到線上環境（若是有須要，能夠配置更多環境）。在本地環境接口都是採用的本地化模擬的接口，而線上環境接口則是線上實際運行的接口。這樣作的好處是：

• 能夠把應用對接口的實現進行一次封裝隔離，如此，若是接口有任何改動，咱們只須要改封裝隔離的代碼，而不須要動其餘地方的代碼，這在大型應用中尤其突出；
• 可以更好的管理代碼，而且一目瞭然當前頁面有多少接口，更具可讀性和移植性。

未封裝隔離的實現（以 jQuery.ajax 爲例）：

// file1.js
$.getJSON('/api/v1/home/index/list', {keyA: 'valueA', keyB, 'valueB'}, res => {...});

// file2.js
$.getJSON('/api/v1/home/index/add', {keyC: 'valueC', keyD, 'valueD'}, res => {...});

...

若是應用比較小，接口實現比較少，其實也沒什麼問題，但若是是複雜應用中，當接口名稱、請求方法、請求參數或返回數據字段發生變化，這個時候就須要處處去找使用的地方，而後處處改。這個時候就須要對接口進行封裝隔離了。

對接口進行封裝隔離，以 see-ajax（對 ajax 的封裝）, see-fetch（對 fetch 的封裝） 爲例：

// ajax1.js （0：線上環境，1：本地環境）
seeAjax.config('list', {
    method: [
        'post' // 線上環境使用 post 方法，本地使用默認的 get 方法
    ],
    stringify: [
        true  // 線上環境序列化請求參數
    ],
    settings: [
        // 自定義 ajax 配置
    ],
    url: [
        'online url',
        'local url'
    ],
    requestKeys: [
        {
            keyA: 'keyF' // 線上環境下把請求 {keyA: 'valueA'} 映射成 {keyF: 'valueA'}
        }
    ],
    responseRefactor: [
        // json 格式化
    ],
    preHandle: [
        // 請求發出以前對本次請求參數的更多操做，如添加、修改
    ],
    postHandle: [
        // 響應以後的操做
    ],
    implement: [
        // 自定義實現接口
    ],
    implementDelay: [...] // milliseconds delay for implement
});


// file1.js
seeAjax('list', {keyA: 'valueA', keyB, 'valueB'}, res => {...});

...

這樣作，即便接口有變化，只須要改 ajax1.js 文件中對名爲 list 請求的配置（包括請求方法，是否序列化請求參數，重定請求鍵名，格式化響應數據等等），而不須要改其餘調用這個接口的地方。

2.3 二者配合使用

本地化接口模擬這兩種方式是從不一樣的角度出發給出的解決方案，能夠配合在一塊兒使用。

3. 先後端並行開發

正常狀況下，前端的開發在完成 UI 或者組件開發以後，就須要等後端給出接口文檔才能繼續進行，這對項目無疑是延長了開發週期，因此若是能作到先後端並行開發，就比較完美了。

先後端並行開發，就是說前端的開發不須要等後端給出接口文檔就能夠進行開發，等後端給出接口以後，再對接好後就基本上能夠上線了。在本地化接口模擬的實現下，咱們就能夠作到先後端並行開發了。

仍是以 see-ajax, see-fetch 爲例：

開發過程當中預約 3 個環境：0（線上環境），1（本地模擬後臺接口環境），2（並行開發環境）

• 並行開發環境：並行開發的時候，預約好本身想要的接口，須要傳給後端的請求參數，以及須要的響應數據；

• 本地模擬後臺接口環境：與後臺對接的時候，開啓本地模擬後臺接口環境，經過對請求進行配置，給到後端想要的數據，獲取本身想要的數據；

  • 經過 method 配置請求方法
  • 經過 stringify 配置是否序列化請求參數
  • 經過 url 配置請求地址
  • 經過 requestKeys 配置請求參數改名
  • 經過 responseRefactor 配置對響應數據進行格式化
  • 經過 preHandle 配置請求發出以前對本次請求參數的更多操做，如添加、修改
  • 經過 postHandle 配置響應以後的操做
  • ...
• 線上環境：通常來講對接完後要進行線上調試，此時的線上調試的工做量較以前已經大大的較低了。

4. 後續

上一篇：先後端分離、web與static服務器分離

下一篇：前端開發規範

參考文章：

1. API 設計: RAML、Swagger、Blueprint三者的比較

更多博客，查看 https://github.com/senntyou/blogs

做者：深予之 (@senntyou)

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）