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
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 .