We often build and deploy web applications specifically for users internal to our organisation. Azure Static Web Apps is proving to be an excellent replacement for Azure App Service in these scenarios. At a high-level the service provides you with a great set of features (outlined in the Azure release notes) Globally distributed content for production apps Tailored CI/CD workflows from code to cloud Auto-provisioned preview environments Custom domain configuration and free SSL certificates Built-in access to a variety of authentication providers Route-based authorization Custom routing Integration with serverless APIs powered by Azure Functions A custom Visual Studio Code developer extension A feature-rich CLI for local development The desired experience?

In my previous post I touched on the things I learnt while migrating ARM templates to Bicep. Bicep also introduces the concept of modules to enable template reuse. I took some time to refactor a composite application that had already been converted from using ARM to Bicep templates, to use Bicep modules. This post will cover the things that I learnt by working through that process. Why modules? From the Bicep documentation:

You may have heard of Bicep, and you may be wondering how much effort it is going to take to move all your ARM templates to this new way of deploying Azure resources. I gave migrating from ARM to Bicep a go. This post will cover going from JSON ARM templates to shiny new Bicep templates that have no errors and don’t contain any warnings or linting issues! Why should you migrate?