痛点

项目中前端和后端通常是并行开发，为了减少等待后端接口开发的时间，我们经常需要在本地模拟后端接口用来测试前端效果。这种做法称之为构建前端Mock。平日里我接触的前端Mock方法大致可以分为以下两种：

1. 本地启动一个静态服务，将所需要的接口写成json文件，根据接口名字将文件放在项目目录下。
2. 再启动一个Server作为Mock Server，使用第三方Proxy将Mock Server的接口代理到静态服务器上。

第一种方法是接触的最多的方法，这做相对来说相对简单，可是带来的弊端也很多。如果项目的接口较少维护起来还比较容易，但是一旦涉及到数十个接口的调用，我们就需要在项目里写新建许多个json文件，如果恰好后端接口的路径又比较长的话，那项目目录将会十分的混乱。比如“ddos/data/details/todayCleanTime.json”，对应的moch目录必须是
<!--more-->
--ddos

|--data

| --details

|--todayCleanTime.json

除此之外，通常情况下接口并不一定就会以json结尾（后端同学也许并不会听你解释。。）
如果按照RESTFUL的格式书写，比如"api/zoos/animals"，那么我们需要准备书写两套调用接口代码，一种以json格式结尾作为本地mock，另一套才是线上接口代码,每次build构建代码时，一定得记得将调用接口的地方改为线上代码。这种做法效率太低了。。
第二种方法则避免了修改接口的麻烦，在本地的Mock Server中模拟一个和线上一样的接口，这样的Mock也更接近于线上的环境。我们当然不用从头用Node或者Php写一个完整的后端服务，已经有许多工具造好了轮子。
我试用了许多工具，最后觉得还是 Json-Server 最为方便。这个工具在github上有11000个star，可见他的火爆之处。有便于其他同类工具，Json-Server基于REST API，配合使用Proxy，效率极其高。下面我简单说下使用方法，以及我在项目中是如何与Webpack整合的。

30秒内创建完整的REST API

安装Json-Server：
npm install -g json-server
在项目中新建一个test.json文件，我们现在要模拟一个/issues和/total接口

\\ test.json
{"issues": [{"id": 101,"text": "something is not right"},{"id": 102,"text": "crash on login"}],"total": {"data": {"exchange_count": "10","share_count": "23","patent_count": "7","article_count": "37","exchangeRecords": []},"success": true}
}

启动服务
json-server --watch test.json --port 9090

访问localhost:9090

现在可以直接按照RESTFUL的规范调用这个接口，并且所做的POST和DELETE等请求，会直接修改test.json文件的值。

➜  ~ curl http://localhost:9090/issues
[{"id": 101,"text": "something is not right"},{"id": 102,"text": "crash on login"}
]%
➜  ~ curl http://localhost:9090/issues/2
{}%
➜  ~ curl http://localhost:9090/issues/101
{"id": 101,"text": "something is not right"
}%
➜  ~ curl -X DELETE http://localhost:9090/issues/102
{}%

除此之外，还可以继续增加路由规则。创建一个routes.json文件

{"/api/": "/","/blog/:resource/:id/show": "/:resource/:id"
}

启动服务

json-server --watch test.json --routes routes.json

如果接口并不是Restful或者比较冗长，你也可以采取路由的方法模拟。

整合Webpack Dev Server

在项目中使用JsonServer，还需要再做点小处理。通常在本地调试的时候我们已经启动了一个静态服务，因此需要用代理服务进行跨域（两个服务分别在两个端口上）。对于使用Webpack打包的项目，已经使用了它自带的webpack-dev-server服务，它很贴心的提供了proxy参数来解决这个问题。在webpack.config.js做以下配置:

devServer:{proxy: {'/gm/api/*': {target: 'http://localhost:9090',secure: false}}}

在package.json中新添加一个scripts:

 "scripts": {"dev": "webpack-dev-server --inline --hot --no-info","build": "cross-env NODE_ENV=production webpack --progress --hide-modules","mock": "node_modules/.bin/json-server --watch mock/db.json --port 9090","mockdev": "npm run mock & npm run dev"},

由于json-server是命令行工具，若没有全局安装需要用相对路径去调用它: node_modules/.bin/json-server 。路径不能少，否则会提示找不到命令哦。
这个世界终于清净啦！在代码中每次调用/gm/api/issues的时候，都会调用到json-server服务去，可以真是模拟线上的接口调用情况。现在可以把所有接口都集中写在一个json文件中，代码里面线上环境和本地Mock也保持了一致，不需要再切来切去啦！
如果你使用的本地静态服务并没有提供代理的功能，那可以使用 阿里的开源工具anyproxy ，同样给力！

加上Faker试试？

如果我们想在Mock的时候生成更多的随机数据，这个时候就需要faker了！faker.js可以用来产生大量的模拟假数据，配合json-server，我来给大家举个栗子��：
npm install faker lodash –save-dev
在项目中新建一个generate.js文件

module.exports = function(){var faker =require("faker");vae _ = require("lodash");return {people: _.times(100,function (n) {return {id: n,name: faker.name.findName(),avatar: faker.internet.avatar()}})}
}

使用命令
json-server generate.js
Done！生成了100条数据，关于faker的更多用法请参照官网，它能够生存许多常见的随机数据，faker.js。

Tips

在使用的过程中，我发现WebStorm有一个很好用的小工具，叫做TestRestfulWebService。（双击shift输入工具名快速唤出）可以直接用来测试json-server。