一个简单的 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 :-)