關於
Mirage 起源於 2015 年，當時我在 TED 工作。我們在那裡有幾個 Ember.js 應用程式，而測試一直是使用 Ember 的重要環節。
大約在這個時候，Ember 核心團隊成員 Trek Glowacki 發布了 Pretender.js，一個模擬 fetch/XMLHTTPRequest 並提供類似 express 的 DSL 來定義路由處理器的函式庫。我們在測試中大量使用 Pretender，我想要一種方法來強制執行我們使用上的一致性。我編寫了 ember-cli-pretenderify，一個專門執行此操作的 Ember 附加元件。
隨著時間的推移，這個附加元件變得不僅僅是連接 Pretender。最大的改變是我加入了資料庫，它實際上只是一些在路由處理器之間共享的全局狀態。伺服器定義也用於開發中，使其既是開發時的工具，也是測試工具。我最終將附加元件重新命名為 ember-cli-mirage，至今仍在使用中。
我早期一直抗拒為 Mirage 增加複雜性，但這感覺是不可避免的。很多人在他們的模擬設置中重複著相同的樣板程式碼。資料庫之後是 ORM，然後是 Serializer 層。Mirage 的大多數 API 都受到 Rails 及其周邊生態系統的啟發。儘管 Mirage 變得更加複雜，但與處理單獨的 API 伺服器相比，它仍然使我們的工作速度快得多，儘管我們在 Rails 中構建伺服器非常舒適。
人們經常問他們是否可以在 Ember 之外使用 Mirage。從一開始，我為了以防萬一我想要將它通用化，就有意避免在 Mirage 的核心中使用 Ember 特有的 API。這證明是一個很好的決定。在 2018 年，我的一些朋友，包括 Charles Lowell 實際上 執行了第一次提取，但當時我仍然主要在 Ember 中工作，並且對維護一個更通用的函式庫沒有興趣。
在 2019 年，Ryan Toronto 和我最終決定扣下扳機。Mirage 感覺是我職業生涯中影響最大的工作，並且將其與任何 JavaScript 工具一起使用似乎都不是什麼大問題。在 2019 年 7 月 19 日，我們發布了一個 ember-cli-mirage 版本，該版本將 Mirage 的所有核心邏輯提取到外部依賴項中。從那時起，我們一直在迭代 miragejs 作為一個完全獨立的函式庫，它現在被用於從 React 到 Vue 再到 Angular 所構建的 JavaScript 應用程式中。
展望未來，Mirage 的使命是成為前端開發人員不可或缺的工具。與我所見過的任何其他方法相比，對網路的本地控制使您能更快地獲得前端程式碼的回饋。在服務提供商每年吸收越來越多伺服器端關注點的世界中，UI 正在成為核心。Mirage 通過授權前端團隊完全模擬其應用程式的邊界，無論另一端是什麼，都完全符合這種架構。