We have been successful deploying Angular web applications to the cloud to be hosted on Amazon S3 static public websites. This works well but the URL could be more compact.
Versioned Deployments
Amazon S3 only supports http unless a more complex CloudFront service is used, but so far it has not been an issue to use https. It has been convenient to deploy applications using a version folder that matches the application version. The latest numerical version can be copied to a generic latest folder that is provided in URLs to users. Deploying into versioned folders eats up a little disk space but there is only ever one latest folder for a product. For example, both of the following links work using two file copies of the deployed files:
This allows archiving different versions of the application, which may be important, for example if data changes every year and looking at old snapshots is helpful. It also allows testing using a versioned folder before copying the files to latest folder. It also allows restoring latest from an older version if necessary if a bug was introduced.
As a comparison, see the following QGIS documentation, which also supports version and latest:
A script is used to upload to Amazon S3, using the version from the application configuration. Changing the version in the configuration file results in a new versioned folder in S3 and optionally allows copying into the latest folder. The resulting S3 bucket has the following. The old versions are fully functional and can be retained as long as desired, or can be backed up and deleted to reduce AWS storage and charges.
Streamlined URL
The main issue with this approach is that latest is included in the URL that users see. It is one thing to access a specific version, for example when troubleshooting or because a user has been told to use for a preview, but latest does not really add any value. The goal of this issue is to evaluate options for retaining the benefits of everything described above but remove latest from the user-facing URL. Experiments can be done first with the default InfoMapper deployment (to http://infomapper.openwaterfoundation.org) and then tried with other websites such as the Poudre Basin Information website. Below are technical considerations:
It would be possible to deploy the application in the root of the bucket so that latest is not needed. However, this would result in the latest version having top level files and also versioned folders under that. The AWS S3 command line could easily blow away the versioned folders during the sync process. And, the different deployments would be mixed rather than being in separate folders as is currently done. Therefore, this does not seem like a good option.
"Redirect" the URL http://poudre.openwaterfoundation.org/#/... to poudre.openwaterfoundation.org/latest/#/..., while still showing the user the URL without latest. Questions:
Is this done via S3 bucket configuration?
Is it done with HTML redirect syntax in index.html file or other file in the deployed files?
Are there any implications to software such as getting confused with URLs and routing, links to resources, etc?
Ideally we want search engines to index the generic URL without latest so that people are pointed to the general URL.
What are the implications for Google Analytics? We recently implemented Google Analytics to index specific Angular app URL routes. Would redirected URLs show up as the generic or the specific. It probably is not that helpful to know how many hits a specific version is getting.
Are applications going to be confused? I have had to use options with curl. Web applications like Poudre Basin Information often provides links to the back-end data files and uses might try to access those links directly and have to deal with redirects. Many sites use redirects so hopefully it is simple to deal with.
Are there impacts on automated testing?
In general, we want to implement the option is that is the simplest to use, least fragile, and does not cause side effects, or if there are side effects they are easily dealt with.
While we are at it, is the # in Angular application URLs REALLY necessary. I have seen some articles saying it is not but have not looked into it. I see some Google applications that use #, presumably because they use Angular and I see other websites that don't have #, even though I suspect they are Angular. The hash appeared when the hash routing approach was implemented. If URLs are going to be streamlined, is getting rid of the hash also fair game?
Are there any potential issues of http versus https?
What if the deployment is to a different environment such as Google Cloud Platform, Apache server, etc.?
We have been successful deploying Angular web applications to the cloud to be hosted on Amazon S3 static public websites. This works well but the URL could be more compact.
Versioned Deployments
Amazon S3 only supports http unless a more complex CloudFront service is used, but so far it has not been an issue to use
https. It has been convenient to deploy applications using a version folder that matches the application version. The latest numerical version can be copied to a genericlatestfolder that is provided in URLs to users. Deploying into versioned folders eats up a little disk space but there is only ever onelatestfolder for a product. For example, both of the following links work using two file copies of the deployed files:This allows archiving different versions of the application, which may be important, for example if data changes every year and looking at old snapshots is helpful. It also allows testing using a versioned folder before copying the files to
latestfolder. It also allows restoringlatestfrom an older version if necessary if a bug was introduced.As a comparison, see the following QGIS documentation, which also supports version and
latest:S3 bucket
A script is used to upload to Amazon S3, using the version from the application configuration. Changing the version in the configuration file results in a new versioned folder in S3 and optionally allows copying into the
latestfolder. The resulting S3 bucket has the following. The old versions are fully functional and can be retained as long as desired, or can be backed up and deleted to reduce AWS storage and charges.Streamlined URL
The main issue with this approach is that
latestis included in the URL that users see. It is one thing to access a specific version, for example when troubleshooting or because a user has been told to use for a preview, butlatestdoes not really add any value. The goal of this issue is to evaluate options for retaining the benefits of everything described above but removelatestfrom the user-facing URL. Experiments can be done first with the default InfoMapper deployment (to http://infomapper.openwaterfoundation.org) and then tried with other websites such as the Poudre Basin Information website. Below are technical considerations:latestis not needed. However, this would result in thelatestversion having top level files and also versioned folders under that. The AWS S3 command line could easily blow away the versioned folders during the sync process. And, the different deployments would be mixed rather than being in separate folders as is currently done. Therefore, this does not seem like a good option.http://poudre.openwaterfoundation.org/#/...topoudre.openwaterfoundation.org/latest/#/..., while still showing the user the URL withoutlatest. Questions:index.htmlfile or other file in the deployed files?latestso that people are pointed to the general URL.curl. Web applications like Poudre Basin Information often provides links to the back-end data files and uses might try to access those links directly and have to deal with redirects. Many sites use redirects so hopefully it is simple to deal with.#in Angular application URLs REALLY necessary. I have seen some articles saying it is not but have not looked into it. I see some Google applications that use#, presumably because they use Angular and I see other websites that don't have#, even though I suspect they are Angular. The hash appeared when the hash routing approach was implemented. If URLs are going to be streamlined, is getting rid of the hash also fair game?httpversushttps?