一個簡單的 mock 工具應該長什麼樣

爲了提高先後端協做開發效率，一個稱手的 mock 工具很重要，結合本人這近半年開發 moky 的經歷，說點淺顯的心得和體會。正如其名 moky = mock + proxy，由於我以爲 mock 和 proxy 已經能夠覆蓋 80% 的場景，所謂二八原則，剩下 20% 功能會犧牲工具自己簡潔性和性能。下面結合場景來看看 mock 工具的設計思路以及我認爲的該有的樣子。

場景

咱們假設如今要作一個網站應用，包括後端和前端（雖然也有 BaaS 和純靜態等方案），繼續假設先後端不是同一我的開發。前端視角看整個項目結構以下：

上部分是客戶端，下部分是服務端，二者交互的數據大體分爲：HTML 頁面、異步接口和其它靜態文件三部分。從開發分工來劃分的話，紫色部分是後端工做（業務邏輯、增刪查改、頁面和異步接口路由……），黃色部分是前端工做（模板邏輯、腳本、樣式等）。

特別注意，若是是 React/Angular/Vue/... 等 MV* 框架構建的單頁應用，這裏的模板不是通常意義的模板引擎的模板了，僅僅是一個入口 HTML 頁面，後端頁面路由邏輯也省了，由於只有一個入口頁。因此把 SPA 跟使用傳統模板引擎構建的應用 放在一塊兒討論並不會影響邏輯，若是有特別注意的會額外提到。

Mock

好了，先後端已經協商好交互的接口了，各自開發了。可是你們總感受哪裏不對勁，特別是前端同窗，由於前端須要邊看效果邊寫，此時後端也纔剛剛開始，若是作到沒有後端支持的狀況下前端也能夠順利寫好頁面？

再看一眼上面的圖，說白了就是前端如何本地模擬 Controller 層的頁面渲染+路由、異步接口路由和靜態文件路由，這兩個抽離出來其實都是數據，這裏提煉下關鍵詞：數據、渲染、路由。

• 數據：這裏數據大多數狀況是 JSON 格式，所以能夠直接本地新建符合要求的 JSON 文件便可（分爲頁面的和異步接口的），這就是常說的 mock 數據

• 路由：這個實現就比較簡單了，本地啓一個簡單的 Server 便可，通常這裏框架路由支持都是很是簡單的

• 渲染：頁面的渲染的過程可使用公式 模板引擎(模板, 數據) 簡單表示，如今就差模板引擎了，而這個通常都是現成的

以上敘述來看，貌似實現一個 mock server 仍是比較簡單的，實際操做中仍是可能遇到一些挫折的，好比：數據不是 JSON 的狀況、路由順序以及錯誤處理、模板引擎對環境的依賴（eg: freemarker 依賴 JAVA），細節很少累述，看下面加了 mock 後的結構：

其實就是把以前的 Controller 又「實現」了一遍，而後數據改成從本地 mock 文件裏取，模板文件和靜態文件也是用的本地的。

Proxy

過了好多天了，先後端都開發的差多了，接下來就是傳說中的聯調階段了。即便以前很明確的定義好了接口和交互的數據格式，可是以前不免有疏漏，需求也可能中途調整過，因此聯調不少時候花的時間並不比開發階段少多少。

來看看咱們原始聯調方式，前端發現問題，前端修改了代碼推送到倉庫，後端拉取代碼部署調試，發現還有問題，繼續上述步驟……這個時間花費甚至可能佔到聯調時間一半！

從始至終，我一直有意無心的強調一個思想：先後端交互關鍵就是數據層面的交互，從數據視角出發，聯調階段其實僅僅把假的 mock 數據換成真的數據而已！這樣的話，在 mock server 基礎上實現 proxy 就顯得很是簡單，僅僅把 Mock 模塊換成 Proxy便可，最終的結構呈現以下：

proxy 會從後端的反向代理獲得正常數據，再交給 mock server 按原來 mock 方式處理。這樣還沒完，仔細看上圖會發現後端渲染那部分被幹掉了，取而代之的是直接返回渲染以前的原始數據，由於只有這樣 mock 和 proxy 模式才能夠無痛切換。

總結

• mock + proxy 基本能夠覆蓋從開發到聯調階段大部分行爲，固然由於應用自己多樣性，僅僅用 mock + proxy 有時候也會有不便利的地方，那就結合其它工具吧；

• 最後一段裏的「後端渲染那部分被幹掉了」，這句話雖然輕描淡寫，實際搞起來仍是比較煩的，由於這跟語言和框架是相關的，四個月前我就曾問過不少人關於 Spring MVC 如何設置，好久都沒獲得答案，後面竟然發現有同窗經過攔截器的方式實現了，並且徹底符合個人預期；

• 文中也有地方說了，SPA 應用和模板引擎構建的應用是不同的，但也僅僅少了頁面的 mock 和 proxy 的步驟；

• 最後，有興趣的話能夠試試 moky，有建議或意見能夠提 Issues :-)