关于
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，然后是序列化器层。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 通过赋予前端团队完全模拟其应用程序边界的能力，无论另一边有什么，都完美地适应了这种架构。