1.5　從Mock服務到API管理平臺

Mock服務雖然滿足了前端工程師在開發階段對模擬數據的需求，但一個顯而易見的問題就是接口文檔通常是由后端開發者維護的，每當接口發生變化時，后端都需要手動更新Mock服務中相應的模板代碼，這種方式非常低效且容易出錯。在現代化前端的工程基礎建設中，我們更希望Mock數據的模板能夠自動同步接口文檔的變動，如果前端工程使用了TypeScript進行開發，那么后端可能還需要編寫大量的接口類型定義代碼，其所包含的信息本質上與接口文檔是一致的，事實上，接口文檔、TypeScript接口定義和Mock.js數據生成模板都可以看作接口定義的一種描述形式，這就意味著它們之間可以相互轉換，甚至前后端用來組裝符合接口要求的數據格式時所編寫的代碼也可以看作接口的表現形式。那么我們是否能夠使用一種抽象度更高的語法來描述接口，然后通過實現轉換器插件的方式來滿足不同場景的需求呢？當然是可以的，這正是“適配器模式”所提倡的代碼組織方式，這樣的設計也符合軟件設計的“開放封閉原則”，當以后有其他基于接口信息的描述形式出現時，只需要添加新的轉換器就可以了。

如果我們從軟件工程的角度來看待編程這件事情，就會發現它其實與工業生產活動高度類似，其本質上都是將原本依賴于人的作業過程逐漸調整為依賴于自動化、智能化的工具，從而持續獲得更加穩定和可靠的結果，意識到“軟件開發是一項持續進行的活動”是高手的基本素養。

這里舉個例子來說明一下，假設你已經搭建了一個API管理平臺，開發者只需要在網頁上通過可視化的方式創建新的API，在頁面內就可以同時得到Mock.js數據模板、JSON格式的接口定義和TypeScript接口類型的聲明，用戶只需要復制粘貼就可以得到需要的代碼，從功能上來說，它的確已經實現了API一致性的需求，然而在真實的開發場景中，接口細節往往會被頻繁更新，可能是后端開發者在開發過程中發現之前的設計不合理，于是修改了接口細節；可能是文檔中聲明某個字段是數字類型，但實際聯調時接口卻下發了字符串類型的數據；也可能是真實的接口中某個字段的拼寫錯誤，這時雖然程序不會報錯，但就是讀取不到需要的數據等，各種各樣的低級錯誤可能會造成大量的時間浪費。

如果僅僅向外歸因，你可以說后端開發者不夠細心，但這對于解決問題幾乎沒有任何幫助，即使后端開發者真的意識到自己的問題而有所改善，這樣的改變也是不穩定的，誰能保證自己一直不犯錯呢？如果換個角度來看，這個問題的本質其實在于我們最初設計的API管理平臺只解決了API文檔化和Mock能力集成等一些開發階段的訴求，并沒有實現包含更新、發布、測試、下線、統計等完整的生命周期管理能力，所以才會在修改和更新接口時產生大量的問題。更有效的做法是擴展平臺的能力，從而減輕使用者的心智負擔，這里提供一個功能更為完善的設計方案，如圖1-1所示。

圖1-1　一種接口管理服務的架構設計方案

在此方案中，后端工程師批量更新接口、推送代碼并合并到指定分支后，提前在代碼倉庫中配置的hook消息就會生效，它能夠通知其他服務某個分支的代碼有變更，收到消息的服務只需要在自動化腳本中執行“git clone”命令就可以獲取最新的API信息，當然也可以獲取其他代碼倉庫中的代碼，這時能做的事情就非常多了，比如拉取前端代碼，根據新的API信息更新TypeScript接口定義及接口請求代碼，然后自動提交代碼并發起MR（Merge Repuest，合并請求），這是不是方便了很多？至于其他諸如多環境管理、流量控制、健康度檢查、度量統計等更豐富的工程能力，只需要在實踐中不斷迭代就可以了。