前言
最新几年前后端分离被提的越来越多, 各家大厂的小程序也是讨论的一片火热, 初始,我是觉得我混淆了很多概念, 我以为的前后端分离,就是JS(Javascripc) 和 Java 的分离, 只要我用了JS, Java提供API, 就是前后端分离了.
随着使用场景的增多,我认为前后端有两种协作方式.
- 服务器渲染
- 前后端分离
差别
服务端渲染
在服务器端就将网页直接生成, 浏览器拿到的是一整个网页,而CSS 和 JS部分在浏览器端执行, 网页的内容部分,由服务器端生成, 这种就是服务器端渲染. 至于我是用NodeJS 还是Python ,还是Java都不重要.
前后端分离
只要HTML网页的内容是在服务器端生成的, 这就是服务器端渲染的方式.
只要你的网页是在浏览器端，内容是通过接口从后端拿到的纯数据，这就是前后端分离
那么总结下两种方式关键区别就是,HTML是在哪儿生成的, 浏览器和服务端传递的是什么, 浏览器和服务端传递的是数据，而在服务器端渲染的过程中，传递的是Html网页。
两种方式的好坏
- 数据量: 前后端分离所传递的数据会小一些, 一般以JSON方式传递,可以极大提高服务器的负载能力，节省服务器带宽，节省电力。服务器只提供数据, 那么之前写的很多API可以直接跨平台的给各种端调用, 可以重复利用代码.
- 体验: 前后端多了一个数据渲染的过程, 服务器端省去了这个过程, 也就是一直提出的首屏渲染问题
- 接耦合: 前后端分离, 传递的数据, Model, 数据怎么展示,全部交给前端处理, 后端只负责提供数据.服务器端渲染中，传输的是Html，后端传给前端的Model，通常是通过Hidden的Input来处理，或者是直接用模板技术生成（JSP，Velocity，freemak, thymeleaf）等。(之前这种方式成为套页面)
- 控制: 网页之间有各种跳转交互，在前后端分离中，跳转的页面控制，全部是由前端来决定。跟后端完全没有关系。在服务器端渲染的方式中，大部分是由后端来决定，少部分是由前端来决定。
- SEO: 很多搜索引擎，不支持SPA方式的SEO。服务端渲染的方式,直接生成的是网页, 所以对SEO支持的很好.
以目前互联网的高速发展, 前端的交互展示已经非常的灵活,酷绚, 体验要求越来越高, 对后端的高并发, 高可用, 高性能, 高扩展的要求也是越来越苛刻, 导致前后端的工程师只关注自己擅长的领域. 所以带来了一系列的问题, 如没有任何接口的约定规范下各干各的,直接影响软件项目的研发时长.
为何要分离开
现有的开发模式基本上都是以后端为MVC模式的方式[图]
这种方式的代码可维护性得到了极大的好转, MVC作为一个久经考研的开发模式有着很好的协作性, 至少让开发者知道什么代码应该写在什么地方, View层(视图层) 变得简单干净. 但是这种依然不能使得前后端分工的那么清晰,典型的问题就是.
- 前端开发重度依赖开发环境，开发效率低
这种架构一般的工程师都有经历, 前端写好Demo交给后端去套模板. 淘宝早期 包括现在依然有大量的业务是这种开发模式. 也不能说没有好处, Demo可以本地开发, 高效,缺点是套模板的时候有可能套错, 来回还需要沟通成本.
还有种方式是,前端负责浏览器端所有的开发和服务器端的View层模板开发. 这样UI相关的代码都是前端去写好, 后端不用太关注, 其实这种开发场景前端开发重度绑定后端环境.
-
前后端职责依旧纠缠不清。
有一个很大的灰色地带是 Controller，页面路由等功能本应该是前端最关注的，但却是由后端来实现。Controller 本身与 Model 往往也会纠缠不清，看了让人咬牙的业务代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养，否则 JSP 就够了。 -
对前端发挥的局限。
性能优化如果只在前端做空间非常有限, 需要和后端合作才能碰撞出火花, 但是由于后端框架的限制, 很难做到优化性能.
综上所述
- 关注点分离
- 各司其职
- 术业有专攻
- 快速的迭代
什么是前后端分离
前后分离的第一阶段(基于Ajax带来的SPA时代) [图]
这种模式下,分工已然很清晰, 前后端的关键协作是Ajax 接口. 看起来已经很美妙, 这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。类似 Spring MVC，这个时代开始出现浏览器端的分层架构： [图]
对于这一SPA阶段，前后端分离有几个重要挑战：
-
前后端接口的约定
如果后端接口写的天马行空, 也不稳定, 那么前端会非常痛苦. 在业界有API Blueprint等方式来约定和沉淀接口. -
前端开发的复杂度控制
SPA 应用大多以功能交互型为主，JavaScript 代码过十万行很正常,大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情.
如何做到分离
首先各司其职
- 前后端仅仅通过异步接口(Ajax / JSONP)来编程
- 前后端各自都有自己的开发流程, Bulid工具, Test集合
- 前后端需要变得相对独立并且松耦合
| 后端 | 前端 |
|---|---|
| 提供数据 | 接受数据返回数据 |
| 处理业务逻辑 | 接受数据返回数据 |
| MVC架构或者其他架构 | MV* 架构 |
| 代码跑在服务器上 | 代码跑在浏览器上 |
开发流程
- 接口文档由后端编写和维护, API变化时更新接口文档
- 后端根据接口文档进行接口开发
- 前端根据接口文档进行开发 + Mock平台
- 完成后联调和测试
Mock服务器根据接口文档自动生成Mock数据, 实现接口文档即API:
规范原则
- 接口返回数据即显示：前端仅做渲染逻辑处理
- 渲染逻辑禁止跨多个接口调用
- 前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现
- 请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现
- GET请求、POST请求==必须包含key为body的入参，所有请求数据包装为JSON格式，并存放到入参body中==，示例如下：
GET
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}
POST
- 相应基本格式
{
code: 200,
data: {
message: "success"
}
}
未来的大前端
目前大多数开发者使用的分离模式都是第一阶段, 基本上还是jquery的一套, 对于一些页面的展示, 数据渲染还是比较复杂的, 不能很好的复用, 对于前端来说还是有很大的工作量.
下一阶段可以在前端工程化方面，对技术框架的选择、前端模块化重用方面，可多做考量
最后阶段就是 Node 带来的全栈时代，完全有前端来控制页面，URL，Controller，路由等，后端的应用就逐步弱化为真正的数据服务+业务服务，做且仅能做的是提供数据、处理业务逻辑，关注高可用、高并发等。
PS: 内容参考实际开发场景, 和相关网络文章(如公众号: 米兜).