Sometimes you don’t want to expose all the operations of your API on APIM. For example, you might have an API that has a lot of operations, but you only want to expose a subset of those operations on APIM. Or you might have an API that has operations that are not meant to be called by external consumers. In this post, I’ll show you how you can expose a subset of your openapi spec via Azure devops on APIM.
Tag: azure
Over the years Microsoft has released ceveral libraries for authentication. We had ADAL. It was ok at the time, but didn’t work with the Azure AD 2.0 authorization endpoints. After some time we got the MSAL library, but it took a while before it was usable. Now new libraries are on the horizon to make it easier for the developers. Well … the constant change of libraries doesn’t make it easier for developers.
Azure API management automatically exposes openapi documentation through the developer portal. But what if your company doesn’t activate the portal? This article describes how you can make the openapi documentation available through your API.
When deploying your Azure API management via ARM templates you want to avoid putting environment depending variables in your template files. But injecting all settings via a parameter file is sometimes easier said than done. In my case, I needed to set an API policy to verify a certificate thumbprint. And that simple thing took me a few hours.
Everyone that worked with ARM templates knows that they are error prone. More often than not it’s a struggle get them right. So, if you don’t want your team to wonder if that 6th floor window isn’t an easier way out, you provide them reusable templates. One problem with linked templates is that they must be publicly available. As not all companies want their resources be publicly exposed, you need to find another way.
Application Insights is often used for logging, but did you really read the name? The goal of Application Insights is getting a good insight view of how your application is working.
Nowadays starting a new project demands a lot knowledge. Besides your programming skills, you also need to know source control, continuous integration and delivery techniques as well as taming cloud solutions. As the time to market decreases and agile working increases your releases, you better start thinking about automating your CI/CD pipeline.
Dotnet core, Azure AD, OAuth and openid connect are all exiting technologies. In this post I will combine them in a Giraffe web application.
With the release of the dotnet 2.0 framework things are really getting interesting. So I tried to combine dotnet core, F# and Azure service bus. Seems reasonable at first, but as F# is quite new to me I struggled to find any tutorial. Apparently everyone is assuming that when you work in F# you’ll be able to figure things out from the C# tutorials. With this tutorial that’s about to change.
As a mobile developer 90% of the time I work on a mac. Visual Studio for Mac is an awesome tool to create Xamarin mobile apps. More than not mobile apps are using services. You can use .NET Core to create APIs but deploying them isn’t so easy on a mac. Sure you can use the Azure CLI, but if you are working with mixed teams Powershell seems to be king to deploy towards Azure.
Azure table storage only supports some types. You can find the list here. Complex types are not supported (maybe later they will be, but today it’s not the case). I needed to store some data that is more complex than just a string. As I didn’t need to search on the objects themselves it was ok to store them as Json.