习惯了前后端完全分离的开发模式,一时难以接受前端 html 托管在后端这种操作。

公司前端项目部署现状

将 html 托管给后端,前端只发静态资源(index.js/index.css),然后通过某种方式去刷 html 的静态资源版本号(?version=时间戳或递增数字)。

原因:HTML 文件不能放在 CDN 上,会被缓存。

比较好的实践

我们先来看看前端项目部署的比较好实践是什么?

出处:大公司里怎样开发和部署前端代码?

可以总结出以下四点:

  1. 配置超长时间的本地缓存 —— 节省带宽,提高性能
  2. 采用内容摘要作为缓存更新依据 —— 精确的缓存控制
  3. 静态资源 CDN 部署 —— 优化网络请求
  4. 变更资源发布路径实现非覆盖式发布 —— 平滑升级

上面文章可是本文的基石,虽然已经过去了 5 年。

公司部署方案优缺点

前端只发布静态资源,只要 html 引用的资源不刷版本号,请求的都是 CDN 上缓存的资源(如果 CDN 有缓存的话)。

(强行)优点

  1. 覆盖发布。服务器不会有大量静态资源文件积累;
  2. 后端可以向 HTML 内注入一些内容,比如用户信息。

缺点

  1. 粗粒度的版本号刷新策略,导致根据文件内容变化选择性更新缓存(对应实践 2)无法实施;
  2. html 托管在后端,导致一定程度的前后端未分离(譬如打包策略变更需要后端配合更改 html)。

照猫画虎

那么按照上面的实践,如何处理比较好呢?

  1. 前端每次基于 content hash(依赖内容摘要算法) 打包生成静态资源文件名(例如 aaa.[contenthash].jsbbb.[contenthash].css),文件名是否变化取决于文件内容是否变化;
  2. 使用前端的 html,前端可在打包过程中自动注入静态资源文件地址;
  3. 静态资源先发布,html 后发布。

再来看看上面的缺点是否被解决了?

1. 粗粒度的版本号刷新策略,导致根据文件内容变化选择性更新缓存(对应实践 2)无法实施

文件名是基于 content hash(依赖内容摘要算法)生成,在发布新的 html 后,若文件内容未发生变化,文件名不会发生改变,依旧使用本地强缓存,若文件内容变化,文件名会发生改变,会请求新的静态资源,达到了选择性更新缓存的效果。

2. 覆盖发布。在 html 刷新版本号前,新用户和老用户可能看到的页面版本(功能)不同

非覆盖式发布,文件名[contenthash]不同不会覆盖,旧的静态资源文件依旧存在。

新的静态资源发布后,新的 html 未发布前这个时间段内,老用户请求到旧的 html,请求的是旧的静态资源,文件名(或者说文件路径)未变化,依旧使用本地强缓存,新用户请求到旧的 html,没有本地缓存,但旧的静态资源未被覆盖,依旧可以请求到,此时看到的都是旧版本内容。

新的 html 发布后,老用户浏览器会选择性更新本地缓存,新用户直接请求新的静态资源,看到的都是新版本内容。

3. html 托管在后端,导致一定程度的前后端未分离(譬如打包策略变更需要后端配合更改 html)

html 完全由前端控制,后端只需要提供 API 即可,前后端真正意义上的完全分离。

缺点:

  • 发生变化的文件 hash 值不同,非覆盖发布,可能造成服务器上无用的静态资源越来越多,但这是可以解决的
  • 后端不能往 html 注入一些内容

结语

项目上线需要配置 Nginx ,流程上还有可以优化的地方。