Current situation of the company’s front-end project deployment

Host the HTML to the back end, which only sends static resources (index.js/index.css), and somehow brush the static resource version of the HTML (? Version = timestamp or increment number).

Better practice

Let’s start by looking at what is a good practice for front-end project deployment?

Source: How do you develop and deploy front-end code in large companies?

The following four points can be concluded:

  1. Configure extremely long local caching – saves bandwidth and improves performance
  2. Use content summaries as the basis for cache updates – precise cache control
  3. Static resource CDN deployment — Optimizing network requests
  4. Change the resource publishing path to achieve non-override publishing – smooth upgrade

The above article is the cornerstone of this article, 5 years have passed, what is the better plan, but also hope big guy give advice.

As a graduate of a year rookie, I will first look at the above article to see the current company release process deficiencies.

Advantages and disadvantages of the company deployment scheme

The front-end only publishes static resources, as long as the HTML referenced resources do not flush the version number, there is no impact on the old users (there is a strong cache, directly request local cache, corresponding to practice 1). Although the new users do not cache, because the static resources are overwritten by the same name, so they request new index.js/index.css resources. As long as the resource doesn’t rely on HTML structure, it doesn’t matter if you see the new functionality. (Note: if you rely on HTML structure, you may have problems requesting new resources. Fortunately, currently single-page applications don’t rely on HTML structure, and a #root node is enough.)

(force) advantage

  1. Overwrite the release. The server does not accumulate large static resource files. (Is that important?)
  2. The back end can inject content into the HTML, such as user information.

disadvantages

  1. A coarse-grained version refresh policy fails to selectively update the cache based on file content changes (corresponding to Practice 2)
  2. Overwrite the release. Before the HTML refresh version number, a new user and an existing user may see a different version (function) of the page
  3. HTML is hosted on the back end, resulting in a degree of separation between the front end and the back end (such as packaging policy changes that require the back end to coordinate changes to the HTML)

difficulty

So according to the above practice, how to handle better?

  1. The front-end generates static resource filenames each time based on content Hash (which relies on data summarization algorithms)aaa.[contenthash].js 与 bbb.[contenthash].css), whether the file name changes depends on whether the file content changes
  2. Using HTML from the front end, the front end automatically injects static resource file addresses during packaging
  3. Static resources are published first, HTML later

Have the above shortcomings been solved?

1. The coarse-grained version update policy fails to selectively update the cache based on file content changes (corresponding to Practice 2)

The file name is generated based on the Content hash. After a new HTML is published, the file name does not change if the file content does not change, and the local strong cache is still used. If the file content changes, the file name will change and new static resources will be requested, which achieves the effect of selective cache update.

2. Overwrite releases. Before the HTML refresh version number, a new user and an existing user may see a different version (function) of the page

Non-overwrite publishing, different file name [contenthash] will not overwrite, the old static resource file still exists.

After the new static resource is published and before the new HTML is published, the old user requests the old STATIC resource with the same file name (or file path) and the local strong cache is still used. The new user requests the old HTML with no local cache, but the old static resource is not overwritten. You can still request it, and all you see is the old version.

After the new HTML is published, the browser of the old user will selectively update the local cache, and the new user will directly request the new static resource and see the new version of the content.

3. HTML hosts the back end, resulting in a certain degree of unseparation between the front end and the back end (for example, packaging policy changes require the back end to cooperate with HTML changes)

HTML is completely controlled by the front end, the back end only needs to provide the API, the front end is completely separated from the back end.

Disadvantages:

  • Changing files with different hash values and unoverwritten publishing can result in more static resources on the server that are useless, but this can be fixed
  • The back end cannot inject some content into THE HTML

conclusion

Some experience is shallow, some references are old, some places may be biased, please be sure to correct.

Moreover, the project will definitely be matched with Nginx when it goes online, so we need to ask for help from operation and maintenance. There is still room for optimization in the process, and the current form is too much restriction on the front end.