What is Immutable Web Apps

official website

Immutable web applications are a framework-independent method for building and deploying static single-page applications:

• Minimize the risk and complexity of real-time publishing.
• Simplify and maximize caching.
• Minimize the need for server and runtime environment management.
• Continuous delivery is achieved through simple and flexible atomic deployment.

Guidelines

The method is based on the principle of strict separation:

• Configure from code.
• Release the task from the build task.
• Dynamic content from static content.

The following concepts define the core requirements of immutable web applications. They have nothing to do with the framework and infrastructure.

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

Static assets are files (javascript, css, images) generated from the construction of the web application code base. When they do not contain any environment-specific content and they are published to a unique, independent location, they become immutable.

Static assets must not contain anything that is environment-specific

All leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment variables at compile time. This approach requires generating static assets for each environment and regenerating static assets for any changes in the environment.

Immutable Web applications refer to environment variables defined in the global scope and refer to one of the following two ways:

• Directly from the window object
• Inject services by packaging environment variables

one example:

Static assets must be hosted in a unique and independent location from the web application environment.

Static assets that do not contain any specific environment can be built once, published to a unique location, and then used in multiple environments in a web application.

These static assets have the same qualities as the javascript libraries hosted on the Content Delivery Network (CDN) (Google Hosted Library, cdnjs, jsDelivr, UNPKG):

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

The location of the above jquery library is referenced by countless web applications, independent of the application, and the only version.

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

Similarly, the location of the web application javascript file is unique and hosted in a location dedicated to static assets. The static asset web server is a repository of web application versions.

Configure the static assets for long-term caching

Static assets that do not contain any environment-specific content and are hosted in a unique and permanent location can be configured to be cached by the browser (almost) indefinitely:

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

index.html is a deployable configuration

The HTML document (usually index.html) of a single-page application is not static. It varies depending on the environment and deployment destination. An HTML document is a combination of environment-specific configuration and immutable static assets that define a web application.

index.html contains fully qualified references to static assets.

Look at an example:

index.html must never be cached

Note: In order to allow immediate changes to the web application environment, index.html must never be a browser or a public cache that cannot be cleared on demand:

cache-control: no-store

Immutable Web applications separate the publishing task and the build task into two different workflows.

Construct

The code base of an immutable web application is responsible for building static assets and publishing them to a static web server. Each state of the code base can be represented by a set of static assets in a unique location. Not every state of the code base needs to be published, but any single state of the code base does not need to be published multiple times.

Generally, a code base is a source control code repository integrated with a continuous integration system that can build, version control, and publish static assets to a static web server.

An example of this might be:

An Angular project hosted in a GitHub repository. When the commit is pushed to the master branch, the repo is integrated with TravisCI to build and version assets. Versioned assets are published to the only place in the AWS S3 bucket.

release

The index.html files are managed independently of the code base, and they serve as a checklist for each environment. They should be treated as configuration files and managed accordingly. In addition, there needs to be a mechanism to modify or replace index.html in each web application environment. The behavior of changing index.html is actually a deployment.

An example of this might be:

A set of index.html files, one for each environment, hosted in the Github repository. This repository is integrated with TravisCI to publish the index.html file when modified to an AWS S3 bucket. There is an index.html and S3 bucket dedicated to each web application environment.

The work flow of this separation of build and release, its underlying basic settings are shown in the following figure:

The infrastructure supporting immutable web applications consists of three parts:

• Web application server: A static web server that hosts the web application environment by providing index.html.
• Static Asset Server: A static web server used to host immutable static assets.
• API: One or more publicly exposed endpoints to interact with the web application backend.

Building static assets is a complex process that usually involves:

• Dependency resolution
• Download the library file
• Transpiling
• Minifying
• Bundling
• Uglifying, Code Splitting, Tree Shaking, * Autoprefixing…

These processes are very time consuming, rely heavily on external dependencies, and often run in seemingly uncertain ways. They are not processes that should end by immediately releasing the generated assets to the production environment without verification. Even the act of publishing multiple large static assets is a process that can be interrupted and leave the web application environment in a corrupted state.

Immutable web applications are generated once and published once to a certain location. This process occurs before the real-time release. They can be verified in the staging environment and promoted to the production environment without the need to regenerate with a significantly reduced risk.

Atomic live releases-Atomic live releases

Real-time publishing of immutable web applications is the act of publishing a single index.html file. Deployment is instant, all assets can be used immediately, without any risk of cache being destroyed at the time of publishing.

Rollback is as risky as deployment, and it is usually more risky. For immutable web applications, the same quality of deployment applies to rollbacks. It is worth noting that in the case of a rollback, most browsers will still cache the previous assets.

In case the browser tries to load the old version of index.html, all the assets of the previous version are still available and undamaged.

Simplified caching strategy

Managing cache control headers can be daunting, especially when the web application infrastructure leverages the common cache used by CDN. The two simplest concepts in caching are: "Always Cache" and "Never Cache". Immutable web applications include these concepts, completely separating code that can be "always cached" from the configuration of "never cache".

Simplified routing strategy

Leading application frameworks do not separate the location of static assets from index.html in their deployment recommendations. Instead, they recommend adding routing rules to the web server to return index.html for all paths that are not resolved as physical files.

The implementation of these routing rules may vary from Web server to Web server, and errors usually cause the path to resolve to the wrong resource.

Separating index.html hosting and static assets can eliminate this risk. The static asset server always provides the physical file represented by the url, and the web application server always provides index.html for any url.

Immutable web applications are usually closely related to the following concepts:

• Modern application frameworks: Angular, React, Vue, and Ember enable teams to build increasingly complex single-page static applications. Tools like webpack improve the ability to create, optimize, and manage build artifacts.
• DevOps: The DevOps culture enables web application developers to decompose and re-evaluate their web application infrastructure to better meet the needs of their web applications.
• Mature application patterns and practices: Back-end applications and services are converging around a set of best practices that support portability, scalability, and high availability. This trend has greatly increased the available tools and services, especially those related to containers and container orchestration. Many of these practices are just beginning to be applied to static single-page Web applications.

More original articles by Jerry, all in: "Wang Zixi":