Skip to content

Latest commit

 

History

History
132 lines (95 loc) · 7.48 KB

1.md

File metadata and controls

132 lines (95 loc) · 7.48 KB

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

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 框架为例:

融合在一起的示例:

|-- 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 项目示例:

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

分离之后的 web 项目示例(以 lila 构建工具为例):

|-- src/
    |-- app/
        |-- home/            # 主页工作目录
            |-- index.html   # html 入口文件
            |-- index.js     # js 入口文件
            |-- ...
        |-- login/           # 登陆页工作目录
        |-- about/           # 关于页工作目录
        |-- ...

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

2.2 数据流分离

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

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

3. web 与 static 服务器分离

  • web 服务器:存放运行后端 web 应用的程序,以及前端 html 文件(入口文件)
  • static 服务器:静态资源服务器,存放前端除 html 文件之外的其他资源文件,包括 jscssimages...

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

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

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

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

4. 后续

更多博客,查看 https://github.com/deepraining/blogs

作者:深雨 (@deepraining)

版权声明:自由转载-非商用-非衍生-保持署名(创意共享 3.0 许可证