- What is Angular JS
- Features of Angular JS
- Angular JS Uses
- Angular JS Advantages and Disadvantages
- Angular JS Modules
- Angular JS DOM
- Angular JS Directives and its Types
- Angular JS Data Binding
- Angular JS Controllers
- AngularJS MVC
- Angular JS Expressions
- What is AngularJS Scope?
- Angular JS Scope Characteristics
- Angular JS Event
- Angular JS Filter
Angular Interview Questions
Deployment of an Angular 8 app
Deploying an Angular 8 app
When we are ready to deploy our angular application to a remote server, we have various option for deployment.
Simple Deployment Options
Before fully deploying our application, we can test the process, build configuration, and deployed behavior by using one of these techniques:
Building and serving from the disk
During development, we typically use the ng serve command to build, watch, and serve the application from local memory, using webpackdev server. When we are ready to deploy; however, we must use the ngmodule command to build the app and deploy the build, we must generate the system originated in the methodology.
Both ng build, and ng serve clear the output folder before it creates a project. But only the ng build command is used to build the app and deploy the build artifacts anywhere.
NOTE: The output folder is dist/project name by default. To output, a different folder, change the output path in angular JSON.
We will need two terminal to get the live-reload experience.
- On the first terminal, run the ng build command in watch mode to compile the application to the dist folder.
- On the second terminal, install a web server, and run it against the output folder. For example:
ng build –watch
Like the ng serve command, this regenerates output files when source files change.
The server will automatically reload our browser when new files are output.
NOTE: This method is for development and testing only, and is not supported or secure way of deploying an application.
Requesting services from a different server (CORS)
Angular developers may encounter a cross-origin resource sharing error when making a service request ( a data service request) to a server other than the application’s host server. Browser forbids such claims unless the server permits them explicitly.
There is not anything the client application can do about these errors. The server must be configured to accept the application’s requests.
The –prod meta-flag engages the following build optimization features.
Ahead-of-time (AOT) compilation:
AOT compilation ispre-combines Angular component templates.
deploys the production environment, which enables the production mode.
Itconcatenates our many application and library files into a few bundles.
It is used to removes excess whitespace, comments, and optional tokens.
It rewrites code to use short, cryptic variable, and function names.
Dead code elimination:
removes unreferenced modules and much-unused code.
We can make better decisions about what to optimize and how when we have a clear and accurate understanding of making the application slow.
We waste a lot of time and money optimizing something that has no tangible benefit or even makes the app slower. We should measure the app’s actual behavior when running in an environment that is important to us.
The WebChromeTest tool is another good choice that can also help verify that our deployment was successful.
Inspect the bundles
npm install source-map-explorer –save-dev
Build our app for production including the source maps
ng build –prod –source-map
List the created bundles in the dist/folder.
Run the explorer to generate a graphical representation of one of the bundles. The following example displays the graph for the main bundle.
The source-map-explorer analyze the source map generated with the bundle and draws the map of all dependencies, showing which class is included in the package.
The output for the main bundle is called cli-quick start.
To maximize compatibility, you could ship a single bundle that includes all your compiled code, plus any polyfills that may be needed.
Differential loading is a strategy where CLI builds two separate bundles of the deployed apps.
- The first bundle contains modern ES2015 syntax, takes advantage of built-in support in modern browsers, ships fewer polyfills, and results in smaller bundle size.
- The second bundle contains code in the old ES5 syntax, along with all necessary polyfills. This results in a large bundle size but supports older browsers.
This strategy allows us to continue to build our web application supporting multiple browsers, but only load the necessary code that the browser needs.