痛点
项目中前端和后端通常是并行开发,为了减少等待后端接口开发的时间,我们经常需要在本地模拟后端接口用来测试前端效果。这种做法称之为构建前端Mock。平日里我接触的前端Mock方法大致可以分为以下两种:
- 本地启动一个静态服务,将所需要的接口写成json文件,根据接口名字将文件放在项目目录下。
- 再启动一个Server作为Mock Server,使用第三方Proxy将Mock Server的接口代理到静态服务器上。
第一种方法是接触的最多的方法,这做相对来说相对简单,可是带来的弊端也很多。如果项目的接口较少维护起来还比较容易,但是一旦涉及到数十个接口的调用,我们就需要在项目里写新建许多个json文件,如果恰好后端接口的路径又比较长的话,那项目目录将会十分的混乱。比如“ddos/data/details/todayCleanTime.json”
,对应的moch目录必须是
--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。
网友评论
机智如我于是打开了两个cmd…………