Skip to main content

Posts

Azure Static Web App - Pass authentication info to your linked API

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII -  API integration Part XIV – Bring your own API Part XV – Pass authentication info to your linked API If you have read my post yesterday, you know that you can link an existing API exposed through Azure API Management, an Azure App Service or Azure Container Apps to your Azure Static Web App. When using th
Recent posts

Azure Static Web App - Bring your own API

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII -  API integration Part XIV(this post) – Bring your own API In the last post in this series, I explained that with every Static Web App you get a serverless API endpoint (based on Azure Functions) for free. However you have also the option to bring your own API. This can be an Azure Function but also an API expos

Microsoft.Extensions.DependencyInjection–Register a type with all its interfaces

After using other DI containers like Microsoft Unity, StructureMap and Autofac, I'm now using the built-in Microsoft.Extensions.DependencyInjection DI container most of the time.  The default DI container lacks some more advanced features that these other containers have, but for most use cases it is sufficient. Most of the time when registering a type as a service, you want to register it with the interface it implements: To simplify this I created an extension method AsImplementedInterfaces that register a type with all its interfaces: To use this method, you call any of the Add methods on the IServiceProvider and call the AsImplementedInterfaces method afterwards: Feel free to use it in your own projects... Remark: If you are looking for some other convenience methods that can help you when using the default DI container, check out Scrutor .

Microsoft.Extensions.DependencyInjection - Check if a service is registered in the DI container

After using other DI containers like Microsoft Unity, StructureMap and Autofac, I'm now using the built-in Microsoft.Extensions.DependencyInjection DI container most of the time.  The default DI container lacks some more advanced features that these other containers have, but for most use cases it is sufficient. This week I was looking at a way to check if a specific service was registered in the DI container without resolving and constructing the service instance. Turns out that this feature was introduced in .NET 6 through the IServiceProviderIsService interface (what’s in a name). This interface provides a single method that you can invoke to check whether a given service type is registered in the DI container. To use it, you can resolve the IServiceProviderIsService service itself from the container and call the IsService method: Nice!

NuGet–Transitive dependencies

When adding NuGet packages to your .NET projects, it's important to understand the difference between direct dependencies and transitive dependencies . Direct dependencies are the packages that are added directly as a package reference to your project file. For example in this Azure Function project, you see one direct dependency: So knowing and managing your direct dependencies is quite easy. But this package has also dependencies that are not directly added to your project. These are the transitive dependencies. To prevent supply-chain attacks, it is important to have a good understanding of the full dependency treed and know all packages that are used directly or indirectly in our projects. Visual Studio helps you to see and manage these transitive dependencies by making them visible in the NuGet Package Manager: You can hover over any transitive dependency to understand the top-level dependencies that brought it into your project: And you can always promote a tran

Azure Static Web App – API Integration

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII(this post) -  API integration So far I’ve mostly talked about the Static content part of Azure Static Web Apps but I only briefly touched the API integration when talking about configuration . With every Static Web App you get a serverless API endpoint (based on Azure Functions) for free. When using this Managed Fu

An architect is not an evangelist

A trap I easily fall in to as an architect is that I can be become quite enthusiastic about a specific technology. If you are a long time reader of my blog, you certainly have seen me write about specific tools, techniques and products over the years. Unfortunately this enthusiasm got me into trouble a few times as an architect. Because I have an important stake into a project and some influential power it happened that I started spreading this enthusiasm and influenced the team to join my enthusiasm. Sorry team! But this means that I was no longer doing my job as an architect. Instead of seeing the trade-offs ; I fell in love with the good parts and turned blind for the bad parts. Although I know better and that I should  be wary of any tool or technique that promises to make everything better, I couldn’t resist. It's a trap that many architects fall into: becoming so enamored with the positive aspects of a technology that they overlook its shortcomings. In doing so, we negl