官網

不可變 Web 應用程序是一種與框架無關的方法，用于構建和部署靜態單頁應用程序：

• 最大限度地降低實時發布的風險和復雜性。
• 簡化和最大化緩存。
• 最大限度地減少對服務器和運行時環境管理的需求。
• 通過簡單、靈活的原子部署實現持續交付。

準則

該方法基于嚴格分離的原則：

• 從代碼配置。
• 從構建任務中釋放任務。
• 來自靜態內容的動態內容。

以下概念定義了不可變 Web 應用程序的核心要求。 它們與框架和基礎設施無關。

Static assets are independent of the web application environment(s)

靜態資產是從 Web 應用程序代碼庫的構建生成的文件（javascript、css、圖像）。 當它們不包含任何特定于環境的內容并且它們被發布到一個獨特的、獨立的位置時，它們就會變得不可變。

Static assets must not contain anything that is environment-specific

所有領先的應用程序框架（Angular CLI、Create React App、Ember CLI、Vue CLI 3）都建議在編譯時定義環境變量。 這種做法要求為每個環境生成靜態資產，并針對環境的任何更改重新生成靜態資產。

不可變 Web 應用程序引用在全局范圍內定義的環境變量并引用以下兩種方式之一：

• 直接從窗口對象
• 通過包裝環境變量的注入服務

一個例子：

靜態資產必須托管在唯一且獨立于 Web 應用程序環境的位置。

不包含任何特定環境的靜態資產可以構建一次，發布到唯一位置，然后在 Web 應用程序的多個環境中使用。

這些靜態資產與內容交付網絡 (CDN)（Google 托管庫、cdnjs、jsDelivr、UNPKG）上托管的 javascript 庫具有相同的品質：

https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js

上面的 jquery 庫的位置，被無數的 web 應用程序引用，既獨立于應用程序，又是唯一的版本。

https://assets.myapp.com/apps/1.0.2/main.js

同樣，Web 應用程序 javascript 文件的位置是唯一的，并且托管在專用于靜態資產的位置。 靜態資產 Web 服務器是 Web 應用程序版本的存儲庫。

Configure the static assets for long-term caching

不包含任何特定于環境的內容并托管在唯一且永久位置的靜態資產可以配置為由瀏覽器（幾乎）無限期地緩存：

cache-control: public, max-age=31536000, immutable

index.html 是可部署的配置

單頁應用程序的 HTML 文檔（通常是 index.html）不是靜態的。 它因環境和部署目的地的不同而有所差異。HTML 文檔是特定于環境的配置和定義 Web 應用程序的不可變靜態資產的組合。

index.html 包含對靜態資產的完全限定引用。

看個例子：

index.html must never be cached

注意：為了允許立即更改 Web 應用程序環境，index.html 絕不能被瀏覽器或無法按需清除的公共緩存緩存：

cache-control: no-store

不可變 Web 應用程序將發布任務與構建任務分離為兩個不同的工作流。

構建

不可變 Web 應用程序的代碼庫負責構建靜態資產并將它們發布到靜態 Web 服務器。代碼庫的每個狀態都可以由位于唯一位置的一組靜態資產表示。并非代碼庫的每個狀態都需要發布，但代碼庫的任何單個狀態都不需要多次發布。

通常，代碼庫是與持續集成系統集成的源控制代碼存儲庫，該系統能夠構建、版本控制并將靜態資產發布到靜態 Web 服務器。

這方面的一個例子可能是：

一個托管在 GitHub 存儲庫中的 Angular 項目。當提交被推送到主分支時，repo 與 TravisCI 集成以構建和版本資產。 版本化資產發布到 AWS S3 存儲桶中的唯一位置。

發布

index.html 文件獨立于代碼庫進行管理，它們充當每個環境的清單。 它們應被視為配置文件并進行相應管理。 此外，需要有一種機制來修改或替換每個 Web 應用程序環境中的 index.html。 更改 index.html 的行為實際上是一種部署。

這方面的一個例子可能是：

一組 index.html 文件，每個環境一個，托管在 Github 存儲庫中。該存儲庫與 TravisCI 集成以在修改為 AWS S3 存儲桶時發布 index.html 文件。有一個專用于每個 Web 應用程序環境的 index.html 和 S3 存儲桶。

這種構建和發布分離的工作流，其底層基礎設置如下圖所示：

支持不可變 Web 應用程序的基礎架構由三部分組成：

• Web 應用程序服務器：通過提供 index.html 來托管 Web 應用程序環境的靜態 Web 服務器。

• 靜態資產服務器：用于托管不可變靜態資產的靜態 Web 服務器。

• API：一個或多個公開暴露的端點以與 Web 應用程序后端交互。

構建靜態資產是一個復雜的過程，通常涉及：

• 依賴解析
• 下載庫文件
• Transpiling
• Minifying
• Bundling
• Uglifying, Code Splitting, Tree Shaking, * Autoprefixing…

這些過程非常耗時，嚴重依賴外部依賴性，并且通常以看似不確定的方式運行。它們不是應該通過立即將生成的資產發布到生產環境而無需驗證來結束的過程。即使發布多個大型靜態資產的行為也是一個可能被中斷并使 Web 應用程序環境處于損壞狀態的過程。

不可變 Web 應用程序生成一次并發布一次到某個位置。此過程發生在實時發布之前。它們可以在暫存環境中進行驗證并提升到生產環境，而無需以顯著降低的風險重新生成。

Atomic live releases - 原子實時發布

不可變 Web 應用程序的實時發布是發布單個 index.html 文件的行為。 部署是即時的，所有資產都可以立即使用，而沒有任何緩存在發布時被破壞的風險。

回滾與部署一樣有風險，而且通常風險更大。 對于不可變 Web 應用程序，部署的相同質量適用于回滾。 值得注意的是，在回滾的情況下，大多數瀏覽器仍會緩存以前的資產。

萬一瀏覽器嘗試加載舊版本的 index.html，以前版本的所有資產仍然可用且未損壞。

簡化的緩存策略

管理緩存控制標頭可能令人生畏，尤其是當 Web 應用程序基礎架構利用 CDN 使用的公共緩存時。 緩存中最簡單的兩個概念是：“始終緩存”和“從不緩存”。 不可變 Web 應用程序包含這些概念，將可以“始終緩存”的代碼與“從不緩存”的配置完全分開。

簡化的路由策略

領先的應用程序框架在其部署建議中沒有將靜態資產的位置與 index.html 分開。 相反，他們建議向 Web 服務器添加路由規則，為所有未解析為物理文件的路徑返回 index.html。

這些路由規則的實現可能因 Web 服務器而異，錯誤通常會導致路徑解析為錯誤的資源。

將 index.html 的托管和靜態資產分開可以消除這種風險。 靜態資產服務器始終提供由 url 表示的物理文件，而 Web 應用程序服務器始終為任何 url 提供 index.html。

不可變的 Web 應用通常與下列這些概念具有密切關聯：

• 現代應用程序框架：Angular、React、Vue 和 Ember 使團隊能夠構建越來越復雜的單頁靜態應用程序。像 webpack 這樣的工具提高了創建、優化和管理構建工件的能力。

• DevOps：DevOps 文化使 Web 應用程序開發人員能夠分解和重新評估其 Web 應用程序基礎架構，以更好地滿足其 Web 應用程序的需求。

• 成熟的應用程序模式和實踐：后端應用程序和服務正在圍繞一組支持可移植性、可擴展性和高可用性的最佳實踐進行融合。 這種趨勢極大地增加了可用的工具和服務，尤其是與容器和容器編排相關的工具和服務。 許多這些實踐剛剛開始應用于靜態單頁 Web 應用程序。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的什么是 Immutable Web Apps的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。