Node.js, npm, yarn, & those lock files

The following is my opinion and doesn't represent my employer. 

Install Node.js

If you are like me and work across operating systems and environments (local, container, cloud), you have one or two bullet-proof ways you install Node.js. The Node.js organization has done a great job of listing those. 

I'm sticking with the following:

* For Windows installations - use the Windows download. 

* For all other installations, including VM, Container, Mac, *Nix - use the bash script

Never, under any circumstances, use the apt or apt-get package manager to install Node.js. At this point, that is equivalent to a code-smell. 

NPM vs YARN

NPM should be your package manager of choice when installing an NPM package. If you run into problems, log an issue. 

Debugging Node.js projects with NVM and lock files

The Node Version Manager (nvm) and lock files are for the developer of a project to be able to get back to an exact version of the entire development environment to debug an issue. When you install and use someone's package, you don't need their lock file. NPM doesn't install dependencies for a package based on the log file. 

Check in the lock file so you need to get back to a specific development environment. 

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.

OSS @Microsoft - Docs

Open source software (OSS) at Microsoft allows everyone to see, comment, and contribute to the products, services, documentation, sample code, and SDKs they use. I work at Microsoft and my opinions are my own.

The Microsoft documentation set is not a single GitHub repository. It is many repositories, all with active writers, support engineers, and SLAs.

When you see an issue in the docs or you think a concept or technique is unclear, GitHub repositories allow you to:

• Add an issue, via an Edit button, that is sent directly to the Product group or Content Developer. 
• Create a pull request (PR), that is sent directly to the Product group or Content Developer. 

Is this open source though? Absolutely. You can immediately impact all users of the docs in a positive way.

2 things you can do when logging an issue against the docs:

1. Be specific. Your comment is attached to the entire doc. Be specific where in the doc the issue is and what wording, image, or sample code is problematic. 
2. Be available. Some times an issue is deeper than a simple fix. If someone has a followup question, respond with information if you have it. 

Can you make the fix via a pull request? Yes. That speeds up the process.