I’ve been playing around a lot with bicep recently. I like it because it is much more readable than ARM templates and lets me modularize my deployments easily. Recently, I was writing a module for creating named values in Azure API Management. Here is my service.bicep:
It’s a somewhat well-known facet of development that we don’t consider production problems until it is too late in the development cycle. When we look at taking a Web API into production, we use API management solutions to provide protection, control, and visibility into our APIs so that we ensure we don’t get woken up by a production outage. The things we need to consider are well understood in APIs in general, but what about GraphQL?
When I build a service in the cloud, I describe the infrastructure as a blob of code. There are lots of solutions out there for this. Azure has the Azure Resource Manager (or ARM), which has it’s own JSON or YAML format, for example. Terraform is cross-cloud capable, as is the Serverless Framework. Since I mostly work in Azure, these days, I’be been working more and more with Bicep for my Infrastructure as Code standard. Bicep uses declarative syntax to deploy Azure resources (much like ...
I really thought I was through with Azure Active Directory! Honest! However, another key piece came up. My CloudMud is a real-time pub/sub application that uses SignalR. How do I authenticate to the SignalR connection? Well, like most things, there is a recipe. So let’s get to it.
Recently, I’ve been working on integrating authentication with Azure Active Directory into my Blazor app. I’ve covered the server side and the client side, so what’s left? Well, firstly, I left “secrets” in my client app in the form of an appsettings.json file. They aren’t exactly secret values, but having specific values in there means I can’t have different values for different environments. Similarly, I can’t change those values over time - I have to re-build the app in order to change...