Data API builder becomes Generally Available
Announcing Data API builder General Availability
On May 15th, Data API builder becomes Generally Available.
Data API builder for Azure SQL Databases – Generally Available
It’s been a long road, getting from there to here. Nearly three years ago, Data API builder began as just a dream. How can we reduce the friction for developers wanting to access databases in their client applications? We created Data API builder to solve this, providing secure and feature-rich REST and GraphQL endpoints over databases with zero code. DAB is developer-oriented; it’s open-source and free, even for on-prem databases.
Architecturally, DAB is a dynamic container-based, configuration-driven runtime. It’s an ASP.NET project written in C# and published under the MIT license. We use ChilliCream’s Hot Chocolate for GraphQL and FusionCache for in-memory cache. We also use Swashbuckle, Polly, and several other libraries that every developer uses in well-designed API projects.
REST endpoints
DAB offers REST endpoints with native OpenAPI support and Swagger for developers, including in-memory caching and support for OData-like query string keywords. REST in DAB is standard and typical; it is configured per-entity with granular security and flexible database policies.
GraphQL endpoints
DAB provides GraphQL endpoints with automatic schema generation and Banana Cake Pop for developers, including relational queries and nested Create mutations. GraphQL in DAB can exist with or without REST endpoints and supports the same granular and flexible security features.
Ridiculously flexible
Whether your solution is exposing a data clearinghouse, enabling a mobile application, or just playing around with an Azure database, DAB supports you. It natively connects to several backend stores, including NoSQL (Cosmos DB) and relational (Azure SQL, etc.). It also supports multiple databases simultaneously.
Data API Builder has been a bit of a dream come true for our team. We are starting to modernize all our APIs across the organization. Writing APIs from scratch was going to be a significant effort in that initiative. Data API Builder has completely changed the game for us. Not only will it now take a fraction of the time that we had planned, but the resulting APIs will also be far more mature and feature rich than we could have ever built on our own. We have begun to promote DAB within the company and believe that once other teams understand that power of the tool, they will race to adopt it as well. – Jeremy Syme, Engineering Manager, Bluetooth Special Interest Group, Inc.
Container-based
DAB is a standard Docker-friendly container. It is completely stateless and scalable. Run it in your own environment or in the cloud, it doesn’t matter. Run one or several containers against a single database or against several databases. The approach is up to you. https://aka.ms/dab/registry
Enterprise friendly
Enterprise customers demand features like Microsoft Entra Identity integration and Application Insights and CI/CD support. They also scale and require some crazy topologies. DAB delivers with flexibility, as well as the scale and performance to meet every workload.
Azure friendly
DAB with Azure Static Web Apps offers a seamless solution for integrating your database with front-end applications through its cutting-edge data connections feature, currently in preview. DAB seamlessly integrates with Azure Container Apps, Azure Container Instances, Azure Kubernetes Services, and Azure Web Apps for Containers, while also extending support to custom on-premises deployments.
Feature rich
Every endpoint requires a retry policy, comprehensive logging, in-memory cache, and the ability to map columns and filter results. But they also need solid documentation, a standards-based interface, and robust error handling. You could build it, but Data API builder already has.
Less code, more engine
Engineers love the techniques and technologies DAB uses. It’s what you would build – you just don’t have to. DAB dramatically reduces a codebase, eliminates suites of tests, and shortens CI/CD pipelines; it introduces capabilities typically reserved for the largest teams. Yet incredibly simple.
Rapid development
An early adopter, Nightingale HQ in the UK, writes sustainable software under EU contracts – mostly exposing data clearinghouses through data APIs. They recently published a white paper on their business which highly leverages Data API builder.
DAB speeds this process by only requiring the developer to control the Entity Type definitions from which the subsequent .NET types are built. Based on a rough estimate from prior projects it takes a developer a week to create a simple API representing the models and queries required by a small application, this includes researching the database schemas, writing, and testing the endpoint logic, and writing a .NET client to consume it. Amending a single endpoint to represent a significant logic or model change takes half a day to a day. Through using DAB, we have found a developer can create an API in a matter of hours and amend endpoints in minutes. If realised, these savings not only represent a reduction in time-to-result but also an implicit carbon saving during the development process. – Chris Wilson, NightingaleHQ
What does it mean to be open source? That we work and think in the open. The code is right there; we collaborate with projects like HotChocolate and FusionCache. We have a monthly community standup hosted on YouTube, our issues and discussions are managed in GitHub, and – most of all – we accept your pull . https://aka.ms/dab
Great documentation
The Data API builder team has put in a lot of time to make our docs complete and easy. We’re full of quick starts, tutorials, and conceptual articles meant to help you get started. Our reference docs are comprehensive and always evolving. Check it out at https://aka.ms/dab/docs
Command line
Our CLI is a cross-platform dotnet tool you install like this:
dotnet tool install Microsoft.DataApiBuilder --globalThen, in three lines, you can initialize, validate, and spin up an endpoint on Windows, Linux or MacOS and immediately start consuming data and building client applications. This is a simple example, but a larger and more complex database is fine, too.
dab init --database-type mssql --connection-string "@env('my-connection-string')"
dab add Book --source dbo.books --permissions "anonymous:*"
dab startIt’s worth noting that Data API builder deeply supports environment variables throughout its configuration file. This is the best way to pass secrets. We also support local ENV files for engineers wanting to limit the scope of local environment variables during development.
Getting Started and Contributions
To get started with Data API builder, explore our comprehensive documentation and step-by-step guides: We look forward to your feedback and contributions. Join our GitHub Discussions, provide feedback, or start a conversation about our roadmap.
Final Thoughts
The journey from public preview to General Availability has been rewarding, and Data API builder is ready to help developers simplify database interactions, enabling more time to focus on creating outstanding user experiences and architectures.
Thank you to our community. Join us here.
8 comments
I’m curious, it feels like this is just another iteration of what OData was trying to achieve. Why this project over investing in OData? And where do you feel like this will be better?
OData is an OASIS standard that defines how REST APIs should be. This project is a low code/configuration only approach to spinning up a web server that adheres to the OData standard and helps you access your databases in a RESTful manner in a matter of minutes. Besides REST, it also helps to configure and spin up GraphQL APIs on top of your data estate.
Hi Chris, I think what you mean is that GraphQL feels like OData, not Data API builder – and you would be right. Both are attempts to give consumers control over complex payload construction. In the case of OData, it’s all in the query string; in the case of GraphQL, it’s all in the query body. In either case, the result is a complex payload tailored to the use case of each client or scenario.
Data API builder is different; it is the engine enabling it. Data API builder is a container-based engine that provides dynamic endpoints over your database with security and other standard features you want in an API. It’s true that DAB allows for GraphQL, but also standard REST – with some hints of OData functionality, too. So, even though I understand why you might have thought what you did, I hope now you can see DAB is a different category.
One last note worth mentioning is that OData is basically a third type of API with REST and GraphQL. Though OData uses REST, generally, a RESTful API has a very different profile – simpler – than an OData endpoint. Today, Data API builder supports dynamic REST and GraphQL endpoints only, representing easily 90%+ of all the API implementations in the known universe. OData, though less common, remains the backbone of several important Microsoft services, including Microsoft 360; someday we might introduce OData into DAB because it is so powerful, but that is certainly not in our short-term plans.
On your question as to ” where do you feel like this will be better”. Although, DAB can be used with any application that uses REST or GraphQL as a backend, In addition I think what really stands out for the DAB projects IMO is that it brings database closer to the edge provider, for example edge providers like Cloudflare, vercel, netlify etc are all based off Javascript V8 or deno which doesnt have full set of API’s to interact with a database so the best solution is to use REST APIs to access database.
This looks really nice. Great work!
The callout to FusionCache was great. Never heard of it before now. Exactly what .NET has been sorely lacking!
Under the “Ridiculously flexible” headline, it says: “It also supports multiple databases simultaneously.”
Does that mean I could generate a REST API Endpoint with DAB that queries
– Database A and retrieves Entity A from there
– Database B and retrieves Entity B from there
and than returns a DTO C that contains only needed properties of Entity A and B?
The scenario you described can be achieved via a GraphQL query that retrieves needed properties from Entity A and B. If you need to stick to REST APIs, the flexibility is you get separate REST endpoints for both the entities A and B backed by objects from different databases. Data API builder should be configured via multiple configuration files to achieve this flexibility.
Thanks for your reply.
Sounds interesting and I will give it a try in one of my next projects.
Looking forward to upcoming releases of DAB 🙂