The Azure Static Website might sound like a chunk of space on an Apache server that you FTP an angular site to, but it’s far more than that. What they’ve actually done may seem like overkill, but I’ve really come to be impressed.
The first thing is, it’s not a static website. This is actually a full linux machine running in a container. It literally makes a linux box, then does an npm run to build your site using a config file called static-webapp.config.json, where you can configure the fall-back webpage (ie. everything goes to index.html so angular can take over routing), and your normal package.json file.
Here’s what makes it different:
you can define a directory as “api” and in that directory, you can assign it to an azure function or webapp. What that means is you can keep your API server separate, and if you want to test, you can simply change your YAML document to target a different API server for testing. But the front-end sees it as a directory within the static site that holds the endpoints for your APIS – eliminating problems with CORS.
Updates
The git integration with Azure DevOps is extremely simple and fast. (I’ll write up an example later on.) What makes this different than our past method is that azure never has a point where you’re swapping files. If you’re on a simple FTP connection on a static server, then your going to have a moment where you won’t have any files there OR you may have too many files. Azure seems to simply redirect your domain to the new container, so it’s more like a change on NGINX, where you point to a different container rather than actually changing the files. That makes updates seamless.
There may be more features or drawbacks, but my initial impression after a week is pretty good. I’ll be changing my clients over to this method for the future.
