Why Frontend Deployment Is Harder Than You Think

Simple deployment

Run npm run build to generate a dist folder, hand it to backend developers, and deploy the whole project together. In modern split‑frontend/back‑end setups the dist folder is served by an Nginx web server; the static files are placed in a configured path and API requests are proxied with proxy_pass to avoid CORS issues.

Why basic hosting is insufficient

Large‑scale services (e.g., BAT) face massive traffic and strict performance targets. Re‑loading a CSS file like a.css on every request wastes bandwidth. Even a 304 "Not Modified" response still requires a round‑trip, which is unacceptable for ultra‑high performance. 304 To eliminate any request, the article recommends forcing the browser to use local cache via Cache‑Control or Expires headers, thereby removing the network round‑trip entirely.

Content‑hash based URLs

When a file changes, its URL should change accordingly so that only the modified resource is re‑downloaded. The solution is to compute a digest (e.g., MD5, SHA) of the file content and embed that hash in the filename or URL. This creates a one‑to‑one mapping between file content and URL, enabling precise cache invalidation.

Deployment order dilemma

Deploy dynamic pages first, then static assets: users who visit during the interval load the new page with old assets, causing style breakage until the old assets expire from cache.

Deploy static assets first, then dynamic pages: users with cached old assets see the old page correctly; users without cache may load the new page with old assets, also leading to mismatches.

For low‑traffic projects a manual “night‑time” sequence (static first, then page) can reduce visible issues, but large companies cannot rely on absolute low‑traffic windows.

Non‑overlapping release strategy

By naming static files with their content hash, a new version of a changed file is published under a new path, never overwriting the existing file. The recommended workflow is to fully deploy all static resources first, then perform a gray rollout of the new page.

Gray deployment with Nginx

Most gray‑release systems are built on Nginx. The principle is:

Initially route all traffic to service 1 and assign different cookies to users.

On subsequent requests, Nginx reads the cookie and forwards the request to either the old or the new service, achieving traffic splitting.

By gradually increasing the proportion of traffic (e.g., 5 %, 10 %, 50 %, then 100 %), the impact of potential bugs is minimized.

Conclusion

The article demonstrates that front‑end deployment involves more than just copying files: it requires cache‑friendly URL design, careful ordering of static and dynamic releases, and robust gray‑release mechanisms to maintain stability in production.