Skip to main content

Azure - Data API Builder

While browsing through Github, I discovered the following project: Data API builder for Azure Databases(DAB).

With data API builder, database objects can be exposed via REST or GraphQL endpoints so that your data can be accessed using modern techniques on any platform, any language, and any device. With an integrated and flexible policy engine, native support for common behavior like pagination, filtering, projection and sorting, the creation of CRUD backend services can be done in minutes instead of hours or days, giving developers an efficiency boost like never seen before.

Sounds cool and a perfect fit for a small application where you only need an API to expose some data. Let’s give it a try!

Setup

Data API builder provides a CLI tool to help us with the configuration and the setup of our project.

Install the tool using the following command:

dotnet tool install --global Microsoft.DataApiBuilder

Now that the tool is installed successfully, we need to create a configuration file specifying our connectionstring to the database we want to connect to.

Remark: We can connect to both (Azure) SQL Server, Azure CosmosDB, Azure MySQL and Azure PostgreSQL.

Run the dab init command to generate our config file:

dab init --database-type "mssql" --connection-string "Server=localhost;Database=<database-name>;User ID=<user>;Password=<password>;TrustServerCertificate=true" --host-mode "Development"

This will create a new config file looking like this:

Exposing tables

Now that the basic setup is done, we can start specifying which entities we want to expose.

Therefore we need to run the dab add command:

dab add Catalog --source dbo.catalog --permissions "anonymous:*"

This will update our config file with the following information:

Run our API

In fact, that is it. The only remaining thing we need to do is run our api:

dab start

Now we can query our API through both a REST and GraphQL endpoint. Of course I want to try the GraphQL endpoint(I used Postman in this example):

Love it!

Labels:

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:
Read more

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

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

As long you are running your Angular application at a root URL (e.g. www.myangularapp.com ) 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. www.mywebsite.com/angularapp ) 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: https://angular.io/guide/deployment --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
Read more