前后端分离、web 与 static 服务器分离

发表于 | 更新于: | 分类于 |
字数统计: 1.7k | 阅读时长 ≈ 6

1. 为什么需要 “前后端分离、web 与 static 服务器分离”

web 前端的发展历史大致可以分为两个阶段：node 之前与 node 之后。在 nodejs 出现之前，前端的发展一直比较缓慢，主要是因为：

  • html/css/js 从设计之初开始，都只为浏览器服务，并且在整个 web 程序中，是以后端为主，前端为辅，前端需要配合不同的后端做出调整（如不同后端语言的模板），因此前端程序往往是与后端程序耦合在一起的；
  • 开发、调试、运行都始终摆脱不了浏览器，并且没有多少可选的工具（如 combo，都是由后端语言在服务器端实现的），不能自动化、工程化的构建前端的代码；
  • 由于浏览器的运行方式，前端代码一直不能有效的做到模块化、组件化，项目也无法版本化管理，项目间也不能很好的共享代码；
  • 浏览器运行速度低下，也是早期前端发展的一大障碍，但 chromium 项目的出现，让前端的运行架上了高铁的速度。

基于以上的原因，前端一直不能很好的开发大型应用，所以在 web 程序中，前端一直处于配角的角色。在 nodejs 出现之后，前端的发展迎来了质的飞跃，带来了我们当时无法想象的便利与潜力。

  • node 拓展了 javascript 的运行环境，并且能够开发服务器端程序，这让前端的开发和运行摆脱对浏览器和后端语言的依赖，让它们成为了可选项；
  • node 使 javascript 拥有了操作本地文件、IO 等权限，于是前端开发人员便可编写各类工具，前端便可做到自动化和工程化；
  • 再结合 npm，前端代码的模块化、组件化，项目版本化，项目间共享代码也就不是问题了。

nodejs 出现了之后，又陆续出现了扩展前端运行领域的工具，如

随着 node 的出现与前端的发展，工程化自动构建便成了开发人员的一个基本需求，这便是我要说的 “前后端分离、web 与 static 服务器分离”；

2. 前后端分离

前后端分离，就是让前端与后端解耦，开发和运行都不再耦合在一起。这样，前端开发人员便可更好的掌控自己的代码，对自己的代码进行调试，优化等等。

2.1 工程分离

首先是工程的分离，也就是代码的分离。这就是说让原来前后端融合在一起的项目分离开，前端一个项目，后端一个项目。

以 python 的 django 框架为例：

融合在一起的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|-- app/                     # 应用主目录
    |-- templates/           # html 模板目录
        |-- app/
            |-- home.html    # 主页html
            |-- login.html   # 登陆页html
            |-- about.html   # 关于页html
            |-- ...
    |-- static/              # 静态资源目录
        |-- js/              # js资源目录
            |-- lib/         # js library 资源目录
            |-- page1/       # 页面1 js资源目录
            |-- page2/       # 页面2 js资源目录
            |-- ...
        |-- css/             # css资源目录
        |-- images/           # 图片资源目录
        |-- ...



    |-- admin.py             # 配置模型models在django原生后台的管理
    |-- apps.py              # 应用级别的配置
    |-- forms.py             # 表单处理逻辑
    |-- managers.py          # 模型处理逻辑
    |-- models.py            # 模型定义
    |-- urls.py              # 路由设置
    |-- views.py             # 控制层
    |-- tests.py

分离之后的 django 项目示例：

1
2
3
4
5
6
7
8
9
|-- app/                     # 应用主目录
    |-- admin.py             # 配置模型models在django原生后台的管理
    |-- apps.py              # 应用级别的配置
    |-- forms.py             # 表单处理逻辑
    |-- managers.py          # 模型处理逻辑
    |-- models.py            # 模型定义
    |-- urls.py              # 路由设置
    |-- views.py             # 控制层
    |-- tests.py

分离之后的 web 项目示例（以 lila 构建工具为例）：

1
2
3
4
5
6
7
8
9
|-- src/
    |-- app/
        |-- home/            # 主页工作目录
            |-- index.html   # html 入口文件
            |-- index.js     # js 入口文件
            |-- ...
        |-- login/           # 登陆页工作目录
        |-- about/           # 关于页工作目录
        |-- ...

本地开发完成后，把构建好的文件传到服务器相应的位置就好了，像上面的例子就需要把 html 文件传到 app/templates 目录下，静态资源文件传到 app/static 目录下。（构建的时候要处理好文件路径引用）

2.2 数据流分离

  • 前后端数据交流使用 json 数据格式，并且推荐使用全 ajax 的方式获取数据，不用传统的模板交流或渲染数据，如 java > jsp、php > smarty；
  • 但有时候为了加快前端响应速度，也可以把 json 数据通过模板返回，但要避免使用后端模板进行逻辑判断渲染。
1
2
3
4
5
<script>
var data = JSON.parse('通过后端模板返回的 json 数据');

// 使用 js 渲染 data 数据
</script>

3. web 与 static 服务器分离

  • web 服务器：存放运行后端 web 应用的程序，以及前端 html 文件（入口文件）
  • static 服务器：静态资源服务器，存放前端除 html 文件之外的其他资源文件，包括 js， css， images…

一般地，还是以 django 框架为例，当前端把代码构建好之后，静态资源传到服务器相应的 static 目录，html 文件传到相应的 templates 目录，启动后端脚本就可运行了。两者不分离主要有以下几个缺点：

  • 前端构建过程中会产生大量的冗余文件，这对后端程序来说十分不友好，比如后端打包程序备份的时候，就会导致包很大；
  • 不方便前端开发人员管理线上代码，并且前端人员能够直接接触到后端代码，也不够安全；
  • 静态资源会占用 web 服务器的资源和带宽，当访问量变大的时候，web 与 static 服务器分离是必然的。

web 与 static 服务器分离之后，前端开发人员便可无顾虑的备份前端代码，清除冗余代码等等。

  • 大多数情况下，会有多个项目共用同一个 static 服务器，如此便需要在服务器划分多个目录来存放静态资源文件；
  • 构建的过程中，构建工具需要保证 html 对 js/css/images... 路径的正确引用，以及 css 对 images... 路径的正确引用，以 lila为例，需要配置 staticServerUrl 为 http://www.static.com/project1