Skip to main content

Using GraphQL in Azure API Management

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 api.
  • After the API is imported you can browse the schema on the Design tab:

  • To test our API endpoint, go to the Test tab. Select the fields you want to fetch or write your GraphQL query from scratch:

  • Click on Send to execute the query and view the returned response:

Next week, we’ll have a look at the other features that Azure API Management has to offer for GraphQL.

More information:

Popular posts from this blog

XUnit - Assert.Collection

A colleague asked me to take a look at the following code inside a test project: My first guess would be that this code checks that the specified condition(the contains) is true for every element in the list.  This turns out not to be the case. The Assert.Collection expects a list of element inspectors, one for every item in the list. The first inspector is used to check the first item, the second inspector the second item and so on. The number of inspectors should match the number of elements in the list. An example: The behavior I expected could be achieved using the Assert.All method:

Angular --deploy-url and --base-href

As long you are running your Angular application at a root URL (e.g. ) you don’t need to worry that much about either the ‘--deploy-url’ and ‘--base-href’ parameters. But once you want to serve your Angular application from a server sub folder(e.g. ) these parameters become important. --base-href If you deploy your Angular app to a subfolder, the ‘--base-href’ is important to generate the correct routes. This parameter will update the <base href> tag inside the index.html. For example, if the index.html is on the server at /angularapp/index.html , the base href should be set to <base href="/angularapp/"> . More information: --deploy-url A second parameter that is important is ‘--deploy-url’. This parameter will update the generated url’s for our assets(scripts, css) inside the index.html. To make your assets available at /angularapp/, the deploy url should

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.