Hosting front-end applications on Azure
I have a catalog of small front-end Javascript apps built with Angular (ng) and React (CRA and Next) I would like to host on Azure.
Hosting on Azure
Azure provides features for a web host:
* Options from big to small - full VM, container, web app, or host static website
* HTTPS and URL - every Azure resource is served via HTTPS with a dedicated URL - no need to buy a certificate or domain name until needed.
No Configuration changes
In order to reduce hidden problems, each front-end app should be installed and running with no configuration change away from the development environment such as a to change the routing of assets from absolute to relative, or folder and subfolder naming.
Consistent & immediate deployment
Once the app is ready to deploy as a collection of static files, there shouldn't be a need to spend time preparing the hosting environment. The front-end system deployment steps should be consistent regardless of which front-end framework the project uses. Deployment failure and debugging should be minimized considering it is just a static front-end app.
Reverse proxy considerations
One solution I've used in previous years requires a reverse-proxy like Nginx and domain name control. This violates the configuration and immediate deployment goals but is a strong consideration when the project is ready for production deployment - the cost and control of an Azure VM makes that an easy choice.
Azure Storage versus Azure Web app
This narrowed the choices to:
* Azure Blob Storage static website - would only handle front-end apps completely disconnected from the back-end
* Azure Web app allows both front and back-end apps.
Both are easy to configure with minimal changes in the Azure portal.
Pricing and availability
* Azure Blob Storage is priced by data storage and throughput
* Azure Web app comes with a monthly charge. Since these are very small hobby apps, Azure Blob Storage seems the best choice for now.
Preparing a test app
To test Azure Blob storage, use the NextJS static export process to build a static app to a local out directory in the local project folder.
How to deploy static files
After creating an Azure Storage resource, in the Azure portal, configure the Static website. This creates a Blob container named $web in the Storage account.
Copy one of the endpoints to use later to test that the static website works.
Upload files to the $web container.
Download and use the storage explorer to move the front-end website files and folders to the new $web container.
Test the static website
Use the URL endpoint provided (when you configured the static website) to verify your website works.
View usage metrics
Azure provides metrics to see how the website is doing.
Hosting more sites
Azure Storage builds out containers with URL routes: domain / container / file. The route includes the container name and doesn't, by default, make assumptions about the content type to return when serving the file.
In order to host more than 1 static website from the same Azure Storage resource, all the of the configuration I'm trying to avoid would need to be done for each site and I would need to manage content types.
Creating a new Storage account is easy, cheap, and very simple so each new site will be hosted in its own Azure Storage resource. When it is time to assign a custom domain name, create a CDN then map the name to that resource.
CLI to create static website
Now that basic usage through the portal is done, use the Azure CLI to create Azure Storage and configure a static website.
Further investigation
The solution needs to solve for management takes such as listing all Static Websites and updating static websites via GitHub hook. Building the automation is a next step.
Hosting on Azure
Azure provides features for a web host:
* Options from big to small - full VM, container, web app, or host static website
* HTTPS and URL - every Azure resource is served via HTTPS with a dedicated URL - no need to buy a certificate or domain name until needed.
No Configuration changes
In order to reduce hidden problems, each front-end app should be installed and running with no configuration change away from the development environment such as a to change the routing of assets from absolute to relative, or folder and subfolder naming.
Consistent & immediate deployment
Once the app is ready to deploy as a collection of static files, there shouldn't be a need to spend time preparing the hosting environment. The front-end system deployment steps should be consistent regardless of which front-end framework the project uses. Deployment failure and debugging should be minimized considering it is just a static front-end app.
Reverse proxy considerations
One solution I've used in previous years requires a reverse-proxy like Nginx and domain name control. This violates the configuration and immediate deployment goals but is a strong consideration when the project is ready for production deployment - the cost and control of an Azure VM makes that an easy choice.
Azure Storage versus Azure Web app
This narrowed the choices to:
* Azure Blob Storage static website - would only handle front-end apps completely disconnected from the back-end
* Azure Web app allows both front and back-end apps.
Both are easy to configure with minimal changes in the Azure portal.
Pricing and availability
* Azure Blob Storage is priced by data storage and throughput
* Azure Web app comes with a monthly charge. Since these are very small hobby apps, Azure Blob Storage seems the best choice for now.
Preparing a test app
To test Azure Blob storage, use the NextJS static export process to build a static app to a local out directory in the local project folder.
How to deploy static files
After creating an Azure Storage resource, in the Azure portal, configure the Static website. This creates a Blob container named $web in the Storage account.
Copy one of the endpoints to use later to test that the static website works.
Upload files to the $web container.
Download and use the storage explorer to move the front-end website files and folders to the new $web container.
Test the static website
Use the URL endpoint provided (when you configured the static website) to verify your website works.
Azure provides metrics to see how the website is doing.
Hosting more sites
Azure Storage builds out containers with URL routes: domain / container / file. The route includes the container name and doesn't, by default, make assumptions about the content type to return when serving the file.
In order to host more than 1 static website from the same Azure Storage resource, all the of the configuration I'm trying to avoid would need to be done for each site and I would need to manage content types.
Creating a new Storage account is easy, cheap, and very simple so each new site will be hosted in its own Azure Storage resource. When it is time to assign a custom domain name, create a CDN then map the name to that resource.
CLI to create static website
Now that basic usage through the portal is done, use the Azure CLI to create Azure Storage and configure a static website.
Further investigation
The solution needs to solve for management takes such as listing all Static Websites and updating static websites via GitHub hook. Building the automation is a next step.
