The environmental needs of a frontend application running in production are different from the development environment we have seen so far in the book.
When we are developing, we look for speed in compilation, powerful debugging, and profiling tools to analyze our code, as well as generating boilerplate code, among other features.
Even though it costs more to process on our local machine, requires more space to generate instrumented bundles to be able to perform debugging, and requires greater network consumption to download development tools, all of this is important for the team’s productivity, and the Angular framework delivers it in a robust ecosystem.
When we are talking about frontend web code running in production, the objective is almost the opposite. We want our code to be as small and optimized as possible, to be downloaded and executed by our users in the most performant way possible.
With this objective in mind, the Angular framework has a robust and simple build tool for generating the production package.
To run it, we need to use the following command in our project folder:
ng build
This command will create the package that we will run in production in the dist folder of our project.
But to deepen our knowledge of the Angular framework, let’s understand what the basis for this build process is. The answer is in the angular.json file. Let’s analyze some important properties of the build:
“configurations”: {
“production”: {
“budgets”: [
{
“type”: “initial”,
“maximumWarning”: “500kb”,
“maximumError”: “1mb”
},
{
“type”: “anyComponentStyle”,
“maximumWarning”: “2kb”,
“maximumError”: “4kb”
}
],
“outputHashing”: “all”
},
“defaultConfiguration”: “production”
}
In the configurations property, we have definitions of the types of environments that we can have in our project. Initially, the Angular CLI creates two configurations: production and development.
In the production configuration, we have the budgets property, which determines the maximum size that our package must have in addition to defining the maximum size that a unitary component must have.
If your project exceeds this size, Angular may show a warning in the production console or even not build your project.
This is important because we need to generate the smallest file possible as this results in a greater perception of performance for our users, especially if they are using a device on a 3G network.
One way to reduce file sizes is to use Angular’s lazy-loading capabilities (for more details on this feature, see Chapter 2, Organizing Your Application).
The outputHashing attribute ensures that the files generated by the application have their names added to a hash.
This is important because most public clouds and Content Delivery Networks (CDNs) cache the application based on the name of the files. When we generate a new version of our app, we want this cache to be invalidated to deliver the new version to our users.
Finally, the defaultConfiguration property determines that if no parameter is passed, the ng build command will execute with the configuration indicated in it, in this case, production.
These configurations can be expanded and new ones created depending on your project needs. In our case, we will leave it with the default configuration.
When running the build in production configurations, Angular performs the following processes:
- Ahead-of-Time (AOT) compilation: Angular compiles templates and CSS files in addition to TypeScript files.
- Production mode: The application has some validations optimized for running in production.
- Bundling: It bundles all component files, templates, services and libraries in files separated by modules.
- Minification: From the files generated by TypeScript, it concatenates and eliminates whitespace and comments to generate the smallest files possible.
- Uglification: It rewrites generated code for variables, function names, and small, cryptic modules to make it difficult to reverse engineer the frontend code delivered to the user’s browser.
- Dead code elimination: Also known as tree shaking, this is the process of not including components in bundles that are not referenced in the code and do not need to be present in the production package.
All these processes are done with the ng build command and with the configuration that was set when your project was created. It is important to note that this process improves with each new version of Angular and is another reason to always keep your project up to date with the latest versions.
In the next section, we will create a Docker image with our code built and run by the Nginx web server.
No Responses