前言
随着互联网的高速发展,各种框架层出不穷,前端页面的展示业务、要求、质量、交互体验越来越灵活、炫丽,响应体验也要求越来越高,工作量越来越繁重!
而后端责着重提供各种服务以及高并发、高可用、高性能、高扩展等。
由于前后端各自关注自己的模块,各自做各自的事情,等到各自的事情都做完啦,才开始对接,然而最终完成和预期并不一样,渐渐地带来一些问题,前后端对接的问题越来越多,往往在后期接口的工作量占比将近50%左右,甚至有可能还会更高!
然而,前后端分离开发效率并没有我们想象的效率那么高!这又是什么原因呢?往往在后期,甚至在产品将要上线,测试的时候,还有很多问题?每次项目的进度,都是前端拖后退,每次老大或者老板问起,后端都说完成啦!前端还没有,往往前端背锅,相信做过前后端分离的人或者做过前端的人都深有感触!我在公司里负责前端的工作,每次每个项目都感觉很吃力,特别连调,为啥这样说呢?
举个我在公司开发的一个项目的列子,前端开发,如果纯静态页面开发,分分钟钟的事情,加上种种业务等,写起来很happy,但是到后端的时候,后端也没有给api,甚至前端充当调试api的测试,各种不通,设置,各种字段不知道什么意思?没有一个完整的rest api的文档,当时我找后台要接口,给你url,自己去掉吧!结果悲剧啦!不通等等,后端各种查问题,最后通啦,返回结构不是想要的,又是一通的更改!终于好啦,到字段映射,更悲剧啦!叫来后端的人,各种问字段什么意思?终于弄懂啦!开始字段映射,各种业务!会发现,前端做的工作越来越多!
相信大多数做前端的人员都深有感触吧!
我在最早接触开发的时候,是我一个同学带进去的一家只有几个人开发的小公司,那是我记得是做微信公众号和推广这一块的,各种页面动画,分享,活动等,那时候前后端并不分离,当时用的是C# mvc,还有aps.net各种页面模板引擎,当时写完后台,写前端模板语法,回想当时,发现那时候关联也没有那么麻烦,前后关联没有那么费事啊,可能都是一个人写, 比较清楚要什么,怎么写,怎么给吧!不过在这家公司技术学到不少,因为各种原因,就离开上海这家公司啦
在第二家公司,是个外包公司,属于被坑进来的吧!当时不太懂,不过在这家公司,只要web前端,不过也是真正的分离,有的项目用的java+freamark 电商类的网站,不过需要后端写好各种control 层,前端才能开始写页面,不过对于前端的我来说,相对减少一些后端的开发量,需要什么字段,直接在modelView直接映射。可能我比较懂一点后端,又或者之前做过c# mvc,个人感觉本质还是有点像的。还有用jsp来写的,不过感觉跟之前也没有任何差别吧!也在这家公司做个H5,这个算分离啦,前期各种页面,后期各种字段映射,有时候借口不通的等等问题,感觉前端一边充当测试api的角色,一边还有字段映射。感觉很悲催!
后端为主的MVC时代
也就是我做c# mvc 和java+jsp(freamark )的时候
在第一次接触MVC这个模式的时候,感觉很高大上,记得但是各种面试公司面试的必备的一个问题,何为mvc,分别代表什么?每一层都在做什么?一开始接触,我就喜欢这样的模式,让我知道自己的代码,该写在哪里,具体做什么?感觉有明确的分工。 虽然感觉前后端分离,但是还在藕断丝连,各种demo,模板嵌套,映射等等,前端对开发环境有很严重的依赖。
基于 Ajax 带来的 SPA 时代
也就是我做H5的时候
不依赖环境,只要做好前后端的关键协作点即可,也就是 Ajax 接口,不过JavaScript代码写的很多,文件变大,在单页中,第一次加载白屏,加载资源过多是个让前端和头疼的事情!
如何做分离
什么是前后端分离?
什么是前后端分离
通过下面一张图就会明白。
通过上图可以明显的看出 ,客户端 ·服务端是分离开的,客户端注重视觉体验以及交互,而服务端是针对客户端提供服务。就像我们所周知的***SPA(Single-page application)*** ,所有用到的展现数据都是后端通过 JSON 但不仅限于 JSON 的方式提供的。
职责分离
后端
- 提供数据和服务
- 处理复杂的业务
- 关注服务层
- 开发和充分利用服务器的性能
前端
- 接收数据和服务
- 简单处理一些小业务,数据,model, view.
- 关注客户端页面渲染,性能,交互
- 优化SEO,性能,加载等
项目开发
- 后端框架建立,数据库设计,字段定义。
- 后端接口文档设计
- 前端框架建立,根据接口文档和字段定义,模拟和建立mock数据
- 前端字段model + 页面view 映射处理
- 联调
- 测试
注意: 1,2,3,4可以交叉开发,并行开发,节约开发时间和成本,减少开发周期。这就是分离的优势。
接口规范
原则
- 接口返回数据即显示:前端仅做渲染逻辑处理
- 渲染逻辑禁止跨多个接口调用
- 前端关注交互、渲染逻辑,尽量避免业务逻辑和复杂的逻辑判断,造成渲染压力和页面加载压力
- 请求响应传输数据格式:JSON,JSON数据尽量简单轻量,避免复杂的结构,造成解析困难
请求基本格式
无论什么请求的方式请求数据包装为JSON格式(key-value),统一发送给后台。在实际项目中为了参数和结构的一致性,在前期设计api的时候要有一定的约束性,GET 一般使用json格式提交,POST使用form提交(key-value),或者无论GET/POST都使用json的形式。
- GET请求
- POST请求
或
请求响应格式
无论什么样的请求,后端都是统一返回json字符串的格式
- 普通的实体格式
{
"status": "success",
"content": {
"id": 2036,
"strategyId": 552,
"timeFlag": 1,
"startTime": null,
"endTime": null,
"timeInterval": null,
"timeUnit": null,
"window": 1,
"windowType": "s",
"step": 1,
"stepType": "s",
"confidenceInterval": null
},
"message": null,
"errorCode": null
}]
注意:这里只处理200的返回
content: 响应返回的实体数据
status: 接口已经通的之后的状态,这个状态不是http 的状态
errorCode: 错误代码,后端有统一的文档来表示
message:成功或者失败的信息
其他的http状态判断统一在拦截器里处理,参考之前博客中写的如何友好的利用XHR的状态,实现前后端的桥梁
- 列表分页格式
{
"status": "success",
"content": {
"total": 124,
"data": [
{
"id": 517,
"name": "ss",
"description": null,
"type": "1",
"riskType": 21,
"monitorModel": false,
"status": false,
"jobId": "",
"ruleTemplate": 1,
"rule": null,
"eventName": "实时规则",
"innerEvent": true,
"alarmAction": 0,
"createTime": 1532577093000,
"createUser": "admin"
}
],
"totalPage": 7,
"pageSize": 20,
"pageNum": 1
},
"message": null,
"errorCode": null
}
content.total: 总记录数
content.pageNum: 当前页码
content.pageSize: 每页大小
content.totalPage: 总页数
content.data: 多个实体对象组成的数组
一些特殊内容规范
- 如何不是双向绑定的框架,在select框、checkbox框、radio框、tree框。由后端接口统一逻辑判定是否选中,通过isSelect标示是否选中,示例如下:
{
"status": "success",
"content": {
"total": 124,
"data": [
....
{
...,
isSelect: 1
},
{
...,
isSelect: 0
}
....
],
"totalPage": 7,
"pageSize": 20,
"pageNum": 1
},
"message": null,
"errorCode": null
}
- Boolean类型: JSON数据传输和返回结构中使用1或者0来表示,1为是/True,0为否/False
- 日期类型:JSON数据传输和返回结构中使用时间戳来表示,除了时间的类型。
导入
如果你想加载一篇你写过的.md文件或者.html文件,在上方工具栏可以选择导入功能进行对应扩展名的文件导入,
继续你的创作。
欢迎进入个人公众号 ,一起学习啊!
[1]: http://blog.jobbole.com/65509/
[2]: https://blog.kaolafed.com/
[3]: http://blog.jobbole.com/65513/
[4]:http://blog.jobbole.com/65534/