The art of simplicity

We’ll continue our exploration of the GraphQL features in Azure API Management by having a look at another feature; the possibility to transform an existing SOAP or REST API in an GraphQL API(Synthetic GraphQL). (If you missed the previous post in this series, have a look here .) Let's walk through the steps. The REST API Let’s first have a look at our REST API that we’ll use in this post. I’ve created an Azure Function that can be called through a GET request and returns a Person object(similar to the GraphQL API I used in the previous post). Here is the related code: Create a Synthetic GraphQL API Let’s see how we can expose this REST API as a ‘Synthetic GraphQL’ API through Azure API Management. Go to your Azure API Management instance in the Azure portal. From the side menu, select APIs in the APIs section: Choose Synthetic GraphQL under Define a new API : In the dialog box specify the following fields: Display name: The name

If you are a regular reader of my blog, you know that I’m a big fan of GraphQL. Even Microsoft is jumping on the bandwagon and last year they announced support for GraphQL in Azure API Management . Until recently I didn't had an opportunity to give it a try, but with the start of a new project, I could finally combine GraphQL and Azure API Management . Import a GraphQL API Let’s walk through the steps to import an existing GraphQL API backend and expose it through Azure API Management. Go to your Azure API Management instance in the Azure portal. From the side menu, select APIs in the APIs section: Choose GraphQL under Define a new API : In the dialog box specify the following fields: Display name: The name you want to use to recognize your API Name: Autogenerated based on the display name GraphQL API endpoint: The endpoint URL where the GraphQL schema is available for download Click on Create to import the GraphQL

I think that documentation is really important. If it is not for my future self, it will be for the poor girl/guy who has to take over my code. Therefore I spend a lot of time in the Azure DevOps wiki to document my application. Today I started to work on a version 2.x of my application. As this new version contains a lot of breaking changes, I immediatelly updated my documentation to reflect these changes. However this 2.x version is still in preview and I want my existing users to still give access to the ‘old’ documentation. So how can I have multiple versions of my documentation available in Azure DevOps? Publish a new wiki branch The answer to this question is by publishing a new wiki branch. My wiki pages live in the same repository as my source code in a separate docs folder: When I started working on my 2.x version, I created a branch for my previous release: To publish this new branch to the wiki, open the Wiki page, open the branch picker, and then choose Pu

In HotChocolate, the GraphQL library I use most of the time, you have the concept of field middleware. It allows you to create reusable logic that will be executed before or after a field resolver. A typical example of built-in field middleware is the support for pagination, filtering and sorting. When executing this middleware, there is a logical order in which you expect this middleware to be executed. For example, you expect that first the returned data will be filtered and then be paginated. In a code-first approach this would look like this: Remark: if you are wondering if this shouldn't be defined the other way around, have a look at this image that can also be found in the documentation : You can do the same thing using an annotation-based approach: When I first saw this code, I was wondering how this could uberhaupt work. I know that in .NET the attribute order should not be respected by the compiler. So although we specified [UsePaging] first and [UseFilteri

Sometimes when working with C# you discover some hidden gems. Some of them very useful, other ones a little bit harder to find a good way to benefit from their functionality. One of those hidden gems that I discovered some days ago is the Half type. The Half type got introduced in .NET 5 as a new floating point type. It extends support for the IEEE 754 specification. In this specification many floating point types are defined, including: binary16 , binary32 , binary64 and binary128 . You probably are already familiar with binary32 (equivalent to float in C#) and binary64 (equivalent to double in C#).  With the new Half type  binary16 is added to the list of supported types. From the documentation : The Half value type represents a half-precision 16-bit number with values ranging from negative 65,504 to positive 65,504, as well as positive or negative zero, PositiveInfinity , NegativeInfinity , and not a number ( NaN ). The Half type is useful in cases when less preci

If you have never heard about the software bill of materials(SBOM), have a look at my previous post here . In short, an SBOM lists all the components that make up your software , or were used to build it. Last month Microsoft open sourced their own software bill of materials generation tool. You can find the source code and corresponding releases in Github: https://github.com/microsoft/sbom-tool . Integrate the SBOM tool in Azure Pipelines As generating an SBOM is typically not something that you do manually, here is how I integrated this in my Azure Pipelines. Remark: I’ll first show you how to do this on Windows as my current build server is still Windows based. If you want to know how to do this on Linux, scroll further down to the end of this post. Go to Azure Pipelines and open the pipeline that you want to edit. Add a new Powershell Task after the build activity and change the Type to Inline. Paste the following script: This will download the t