Building Production Ready Angular Apps
Are you done with development of your Angular based application? Are you planning to take your application into the production environment? Do you want your application to perform smoothly in production? Here are the things you should consider about the configuration and build of your application.
This story is not about the details of the practices, configuration and strategy for taking the Angular applications in production. It is also not a tutorial about how to build Angular apps. This is just a check list of the things you might consider for the smooth operation of your application. Enough of the talking…let’s begin.
Following are the things we are going to have a look further :
- Compilation Method
- Environment Configuration: Production Mode
- Browser Compatibility
- Location Strategy
- Utilizing Caching and Cache Bursting features
There are mainly two compilation methods available for Angular apps
- JIT: Just In Time Compilation
- AOT : Ahead Of Time compilation
For production environment it is recommended that you use AOT compilation. This can be achieved by passing — aot option with ng build command. Read about the compilation methods in details here.
Environment Configuration : Production Mode
Your application should always run in production mode when served to end user. Production mode is optimized by disabling things useful for developers only. This can be achieved by executing enableProdMode function conditionally. While building the app using ng build, pass — environment=prod option, which ultimately uses the configuration stored in environments/environment.prod.ts.
When it comes to supporting majority of the browsers by your web application you should consider to have a look at Angular’s cross browser compatibility features and how to enable those.
You can enable various pollyfills to cover maximum browsers. Have a look at Angular’s cross browser compatibility in details here.
As we know Angular enables us to develop SPAs (Single Page Applications). Client side routing enables us to render different view according to different URLs in a single page. Angular supports following schemes for URL formation:
- Hash (#) Based
- Slash (/) Based (Default)
In hash based location strategy your application URL with some route will look like: www.abc.com/#/dashboard or www.abc.com/#/orders etc.
The URL fragment after # is route name that decides which view should load on the page at client side.
In Slash (/) based location strategy regular address URLs are used for combining site address with client side routes. www.abc.com/dashboard
It is the default strategy in Angular CLI based project.
It is up to you which strategy you want to use for production but you need to consider some things while using Slash (/) based location strategy.
You need to set proper basehref and server side routing for every request containing address of your application to index.html of your application.
Read about Location Strategy in details here.
Utilizing Caching and Cache Bursting features
First thing first, is browser caching of the Web Application good or bad??
So, you guessed it correctly.. it is good but should be under control.
Caching of web pages (including other assets like styles and scripts) is something which is provided by all modern browsers for increasing application’s performance.
But when you release new features to your application which is already in production, this caching feature prevents the user to load latest site resources.
You can overcome this problem by utilizing Angular CLI’s features properly.
Use output-hashing option while building your application using ng build command. It will generate all the build files with different names (Hashed) on every new build. Configure your application server to disable caching of index.html (It is very small in size and we can live without caching it).
Now your application’s index.html page is never cached in browser and user loads it always from server. Other files referenced from index.html are still cached in browser. Whenever new features are released index.html will point to different resources now and will load fresh version and again cache those.
So by following this strategy, we can use caching and cache bursting properly.
People generally complains that Angular build files are too large and may increase application load time. But if you are using caching feature smartly then application will load fast except the first time (After this all large files will be cached in browser).
So I guess we are done with it. The story was a little bit lengthy as i tried to cover all the things in one go. Still this is just an overview of the things under consideration. For going into the details please refer the links mentioned with various sections. Angular CLI’s documentation also explains all possible build options. Exploring those will also be very helpful.
I will be back with some more exciting stuff. Till then..
Keep Learning — Keep Sharing — Keep Rocking