为了提高前后端协同开发的效率，一个好的mock工具非常重要。结合自己近半年开发moky的心得，分享一些简单的心得体会。就像名字moky=mock+proxy一样，因为我觉得mock和proxy已经可以覆盖80%的场景，所谓28%的原则，剩下的20%的功能会牺牲掉的简洁性和性能工具本身。下面结合场景看看mock工具的设计思路和我认为应该是什么样子。Scenario我们假设现在要做一个网站应用，包括后端和前端（虽然也有BaaS和纯静态方案），继续假设前端和后端不是同一个人开发的。从前端的角度来看，整个项目结构如下：上半部分是客户端，下半部分是服务端。两者交互的数据大致分为三部分：HTML页面、异步接口和其他静态文件。从开发的划分来看，紫色部分是后端工作（业务逻辑、增删改查、页面和异步接口路由……），黄色部分是前端工作（模板逻辑）、脚本、样式等）。特别注意，如果是用React/Angular/Vue/...等MV*框架构建的单页应用，这里的模板不是一般意义上的模板引擎的模板，它只是一个入口HTML页面，后端的页面路由逻辑也是Saveit，因为只有一个入口页面。因此，用使用传统模板引擎构建的应用程序来讨论SPA不会影响逻辑。如果有什么特别注意的地方，会另行说明。Mock准备好了，前后端协商好交互接口，各自开发。但是大家总觉得哪里不对，尤其是前端同学，因为前端需要边写边看效果，而后端这时候才刚刚开始。如果没有后端的支持，前端也能顺利的写好页面？再看看上面的图片。说白了就是前端如何在本地模拟Controller层的页面渲染+路由、异步接口路由和静态文件路由。这两次提取实际上是数据。以下是关键词：数据、渲染、路由。数据：这里的大部分数据都是JSON格式的，所以可以直接在本地新建一个符合要求的JSON文件（分为页面和异步接口）。这是常说的话。Mock数据路由：这个实现比较简单，本地启动一个简单的服务器即可。通常，这里的框架路由支持是非常简单的渲染：页面渲染过程可以简单地用一个公式模板引擎（模板，数据）来表示。现在的模板引擎很差，一般都是这样从上面现成的描述来看，实现一个mockserver似乎比较简单，实际操作中可能还是会遇到一些挫折，比如：数据不是JSON，路由顺序和错误处理，模板引擎对环境的依赖（eg：freemarker依赖JAVA），细节就不多说了，看下面添加mock后的结构：其实就是把之前的Controller又“实现”了一遍，然后数据从本地的mock文件改过来，模板文件和static文件也是本地使用的。Proxy用了几天了，前后端开发差了很多，接下来就是传说中的联调阶段。即使之前明确定义了接口和交互数据格式，之前也难免有遗漏，中途可能调整了需求，所以联调的时间往往不亚于开发阶段。来看看我们原来的联调方法。前端发现问题，前端修改代码推送到仓库，后端拉取代码部署调试。如果还有问题，继续上面的步骤……这个时间甚至可能占到联调时间的一半。！从头到尾，我一直有意无意地强调一个想法：前后端交互的关键是数据层面的交互。从数据的角度来看，联调阶段其实就是用真数据代替假的mock数据！这样的话，在mockserver的基础上实现proxy就很简单了。只需将Mock模块替换为Proxy即可。最终的结构是这样的：proxy会从后端的reverseproxy获取正常的数据，然后像之前一样交给mockserver。Mock的处理方式。这还没有结束。仔细看上图，你会发现后端渲染部分被kill掉了，而是直接返回渲染前的原始数据，因为只有这样才能无痛切换mock和proxy模式。综上所述，mock+proxy基本可以涵盖从开发到联调的大部分行为。当然，由于应用本身的多样性，有时候只使用mock+proxy是不方便的，那就结合其他工具吧；最后一段“后端渲染的部分已经被干掉”，这句话虽然是轻描淡写，但是做起来其实还是挺麻烦的，因为跟语言和框架有关。四个月前，我问过很多人有关SpringMVC的问题。很久没有得到答案，后来发现有同学通过拦截器实现了，完全符合我的预期；文章中还有一个地方说SPA应用和模板引擎构建的应用是不一样的，但是它们只是少了页面的mock和proxy步骤；最后，有兴趣的可以试试moky，有建议或者意见可以提出Issues:-)
