前端架构经验谈之一

谈谈历史

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

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

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

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

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

  • electron, nw.js: 让前端可以开发桌面软件;
  • react-native: 让前端可以开发原生app。甚至现在vue也出现来Vue Native解决方案

随着 node 的出现与前端的发展,工程化自动构建便成了开发人员的一个基本需求,这使得前后端分离断定了基础。

前后端分离

前后端分离,就是让前端与后端解耦,开发和运行都不再耦合在一起。这样,前端开发人员便可更好的掌控自己的代码,更高效快捷的开发 web 前端程序。否则,前端对页面的开发与调试总是依赖后端程序,而不能本地运行,这就导致前端开发很耗时,并且毫无意义。

工程分离

首先是工程的分离,也就是代码的分离。这就是说让原来前后端融合在一起的项目分离开,前端一个项目,后端一个项目。包括我们公司的一些旧有php大部分项目,甚至包括一些核心的java项目,都是大部分采用了前后混合开发,导致前端开发人员在调试出现了需要依靠后端人员。

数据流分离

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

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

web与静态服务器分离

  • web 服务器:存放运行后端 web 应用的程序,以及前端 html 文件(入口文件)
  • 静态服务器(cdn),静态资源服务器,存放前端除 html 文件之外的其他资源文件,包括 js, css, images,字体,视频等

web与静态服务器分离是何等的重要?

  • 第一,静态资源会占用 web 服务器的资源和带宽,当访问量变大的时候,web肯定支撑不了,毕竟“我们家”只有10M带宽,与静态服务器分离是必然的,在cdn上不占用带宽哟。
  • 第二,前端构建过程中会产生大量的冗余文件,会导致构建大包很大。

其中“我们家”最新的portal,和cms配置,都符合了上面的特点,前后端分离,而且上传文件(图片),生成功能页面(包括专题页面)之类的,都是直接上传或rsync到远程静态服务器上。

本地化接口模拟,前后端并行开发

当前后端分离开发后,瀑布流方式开发?需要等待后台人员给接口,错了,前端工具何其多,本地接口模拟很easy,而且这种方案和工具也在流行, 本地化接口模拟就是说我们要在本地模拟一个与服务器差不多的环境,能够提供数据所需的接口,进行错误模拟处理等等。

一般来说,本地数据模拟的解决方案有两种思路:

  • 同等模拟服务器环境,就是依据文档,完全按照服务器的接口配置搭建本地的接口服务;
  • 多环境配置&切换,就是从代码的层面配置多个环境(如 线上环境,本地环境),根据是在线上还是在本地切换不同的环境。

同等模拟服务器环境

这种方式基本上不需要在代码层面做更改,因为本地接口与服务器接口基本上一致,包括接口名称,请求方法,请求参数,响应数据。比较常见的有 mock.js,RAML(RESTful API Modeling Language 即 RESTful API 建模语言),Swagger,API Blueprint等。

多环境配置&切换

这种方式是在代码的层面配置多个环境(如 线上环境,本地环境),根据是在线上还是在本地切换不同的环境。

比如,开发的时候切换到本地环境,线上运行的时候切换到线上环境(如果有需要,可以配置更多环境)。在本地环境接口都是采用的本地化模拟的接口,而线上环境接口则是线上实际运行的接口。这样做的好处是:

  • 可以把应用对接口的实现进行一次封装隔离,如此,如果接口有任何改动,我们只需要改封装隔离的代码,而不需要动其他地方的代码,这在大型应用中尤为突出;
  • 能够更好的管理代码,并且一目了然当前页面有多少接口,更具可读性和移植性。

两者配合使用

本地化接口模拟这两种方式是从不同的角度出发给出的解决方案,可以配合在一起使用。