前言

最新几年前后端分离被提的越来越多, 各家大厂的小程序也是讨论的一片火热, 初始,我是觉得我混淆了很多概念, 我以为的前后端分离,就是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模式的方式[图]
image.png

这种方式的代码可维护性得到了极大的好转, MVC作为一个久经考研的开发模式有着很好的协作性, 至少让开发者知道什么代码应该写在什么地方, View层(视图层) 变得简单干净. 但是这种依然不能使得前后端分工的那么清晰,典型的问题就是.

  • 前端开发重度依赖开发环境,开发效率低
    这种架构一般的工程师都有经历, 前端写好Demo交给后端去套模板. 淘宝早期 包括现在依然有大量的业务是这种开发模式. 也不能说没有好处, Demo可以本地开发, 高效,缺点是套模板的时候有可能套错, 来回还需要沟通成本.

还有种方式是,前端负责浏览器端所有的开发和服务器端的View层模板开发. 这样UI相关的代码都是前端去写好, 后端不用太关注, 其实这种开发场景前端开发重度绑定后端环境.

  • 前后端职责依旧纠缠不清。
    有一个很大的灰色地带是 Controller,页面路由等功能本应该是前端最关注的,但却是由后端来实现。Controller 本身与 Model 往往也会纠缠不清,看了让人咬牙的业务代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养,否则 JSP 就够了。

  • 对前端发挥的局限。
    性能优化如果只在前端做空间非常有限, 需要和后端合作才能碰撞出火花, 但是由于后端框架的限制, 很难做到优化性能.

综上所述

  • 关注点分离
  • 各司其职
  • 术业有专攻
  • 快速的迭代

什么是前后端分离

前后分离的第一阶段(基于Ajax带来的SPA时代) [图]
image.png
这种模式下,分工已然很清晰, 前后端的关键协作是Ajax 接口. 看起来已经很美妙, 这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript,浏览器端变得很复杂。类似 Spring MVC,这个时代开始出现浏览器端的分层架构: [图]
image.png

对于这一SPA阶段,前后端分离有几个重要挑战:

  • 前后端接口的约定
    如果后端接口写的天马行空, 也不稳定, 那么前端会非常痛苦. 在业界有API Blueprint等方式来约定和沉淀接口.

  • 前端开发的复杂度控制
    SPA 应用大多以功能交互型为主,JavaScript 代码过十万行很正常,大量 JS 代码的组织,与 View 层的绑定等,都不是容易的事情.

如何做到分离

首先各司其职

image.png

  • 前后端仅仅通过异步接口(Ajax / JSONP)来编程
  • 前后端各自都有自己的开发流程, Bulid工具, Test集合
  • 前后端需要变得相对独立并且松耦合
后端前端
提供数据接受数据返回数据
处理业务逻辑接受数据返回数据
MVC架构或者其他架构MV* 架构
代码跑在服务器上代码跑在浏览器上

开发流程

  • 接口文档由后端编写和维护, API变化时更新接口文档
  • 后端根据接口文档进行接口开发
  • 前端根据接口文档进行开发 + Mock平台
  • 完成后联调和测试

Mock服务器根据接口文档自动生成Mock数据, 实现接口文档即API:

image.png

规范原则

  • 接口返回数据即显示:前端仅做渲染逻辑处理
  • 渲染逻辑禁止跨多个接口调用
  • 前端关注交互、渲染逻辑,尽量避免业务逻辑处理的出现
  • 请求响应传输数据格式:JSON,JSON数据尽量简单轻量,避免多级JSON的出现
  • GET请求、POST请求==必须包含key为body的入参,所有请求数据包装为JSON格式,并存放到入参body中==,示例如下:
    GET
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

POST
image.png

  • 相应基本格式
{
    code: 200,
    data: {
        message: "success"
    }
}

未来的大前端

目前大多数开发者使用的分离模式都是第一阶段, 基本上还是jquery的一套, 对于一些页面的展示, 数据渲染还是比较复杂的, 不能很好的复用, 对于前端来说还是有很大的工作量.

下一阶段可以在前端工程化方面,对技术框架的选择、前端模块化重用方面,可多做考量

最后阶段就是 Node 带来的全栈时代,完全有前端来控制页面,URL,Controller,路由等,后端的应用就逐步弱化为真正的数据服务+业务服务,做且仅能做的是提供数据、处理业务逻辑,关注高可用、高并发等。

PS: 内容参考实际开发场景, 和相关网络文章(如公众号: 米兜).

Q.E.D.

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

脸朝大海, 春暖花开 ----江大脸