Data API builder 2.0 was recently

released. Learn all about what data API

builder is, how it works, what you can

use it for, and get a sneak peek at a

demo this week on Data Exposed.

Hi, I'm Anna Hoffman and welcome back to

Data Exposed. Today we have an exciting

episode with Jerry Nixon. Jerry, thanks

so much for coming on the show.

>> Thanks, Anna. It's great to be here.

Thanks for having me back.

>> Yeah, it's great to have you and today

we're talking about Data API builder,

what it is, what's new, and anything

else Jerry thinks we should know.

Um, so Jerry, let's get right into it.

Can you tell us a little bit about what

Data API builder is and why people

should care?

>> Yeah, absolutely. Data API builder is

one of the things I love talking about

because most people don't believe it as

I describe it. So, the first thing just

to say is before I even tell you how

this fits into a regular architecture,

is this is an open source project for

Microsoft, free license, and there's no

special strings attached. That means you

can use it on prem, you can use it in

Azure, or you can use it even in AWS and

it's totally cool. Where it fits is an

important kind of discussion point and

it really is that in between your

application and the database. One way or

another, your application needs to talk

to your database and either you include

all of that logic in your app, all that

logic in maybe an a an abstracted API

for your app, or you just delete all of

that code, delete the entire section of

your repository, and uh, replace it with

this drop-in replacement of Data API

builder which gives you a REST API

directly into SQL, or a GraphQL API

directly into SQL. And with the release

of 2.0 last month, we now have an MCP

directly into SQL if your application is

an agentic app as well. So, we have done

what every engineer wants to do. If you

had the unlimited time and budget to be

able to build a super duper API with all

of the filtering and pagination and

authentication and all the things built

into it, that's what we've done for you.

Because it's open source, you can go in

and evaluate the code for yourself. See

that it's not exotic. This isn't

code generation or anything like that.

It drops in like a container or a

sidecar process to your website, making

it so that frankly, you don't have to

build the sort of redundant CRUD

operation back into your database. You

can rely on us doing it correctly for

you. And so,

it's pretty sweet. 2.0 coming out gave

us a lot of new features, including the

ability

to cache into Redis, a new

authentication method of OBO or on

behalf of that allows us to pass in

credentials.

And you know, integration with

with Key Vault and all the things that

you would want from an enterprise-grade

ready-to-go drop-in replacement

production API for your app. What's nice

is this is tiny. I could talk about it

for a long, long time because of all of

its features, but it's a tiny, tiny

container that you would drop into your

topology and presto, you have it. And

you just configure it with a JSON file.

Now, that layout that you were just

showing is

really the summary of everything that we

do and why what makes Data API Builder

special. So, that one JSON file that you

provide, the config file down at the

bottom, that is passed into the

container, mounted as a file, and we

dynamically then through the runtime

engine create in-memory abstractions

that map to whatever it is in your

database you're exposing. So, in that

JSON file, you say, "Here's my

connection string, however it is you

connect, if it's managed instance or

username password off or

pass-through, whatever it is." And then

we'll we'll connect to your database.

Then in that

file, you also say here are the tables,

views, and stored procedures that you

want to expose and Azure SQL or in

Postgres or in MySQL or in Cosmos. And

then we go find those, validate that

through the meta metadata, and create

this sort of in-memory schema that as

your application starts to interact with

the the API, we start building the

queries on the back end for you so that

you can interact quickly with the

database. And what's great about it,

Anna, is it takes it so that your

engineering team doesn't have to be a

super duper engineering team that knows

T-SQL and how to craft a really great uh

you know, query. Instead, all you need

is a development team that understands

JSON and HTTP, interacts with an

endpoint like everything else, and then

allow us to take the the surface area of

the API that kind of kind of is a recipe

that constructs that um query for you.

We execute the query on the back end of

the to the database. And what's nice is

we can connect to a any of those

databases as well as any of those

databases simultaneously. So we could

have multiple databases allowing you to

connect to a SQL that's on prem as well

as a SQL that's in the cloud. So with

the release of 2.0, we have closed out

scores of issues that have been in our

backlog that we have just been dying to

do. And little features like compound

paths inside of your um your REST

endpoint to allow you to kind of compose

the type of API surface that you really

want to have exposed. And so a lot of

a lot of it is significant features as

we start to enable the MCP capabilities,

but also

the the small little paper cuts that we

were just wanting to be able to give to

our developer community. And since we're

open source, a lot of this came from uh

contributions from the community as well

as our own engineering team as well. And

open source at Microsoft is special

because unlike open-source anywhere

else, you don't have to worry about

whether or not the maintainer is still

around because

it's actually a product from our

perspective, which means it goes through

all the security reviews regularly. So,

we will get um constant internal

security audits that a normal OSS

repository just doesn't get that, not in

the way that we do. And so, that gives a

kind of another comfort level as an

enterprise is trying to decide if this

is the right way to expose their

database to AP to either a customer

externally or to an internal application

just using the REST endpoint. So, pretty

powerful all the way around. And if I

could just point out one other thing,

that box in the middle is sort of the

engine of Data API Builder. And there in

the in the middle bottom it it were it's

permissions and policies. And one of the

special things that we can do

is apply custom predicates, almost like

row-level security and custom-level

security that you would see inside of

SQL, but we can do that in the API layer

instead. All of this capability is is

still free. And the beautiful part of it

is

if you

if you start to use it, you will

immediately become addicted to it

because there are so many aspects I

mean, imagine a an application you're

writing and you're like, I don't want to

include a database driver. So, you just

delete it because you really only need

the API. And I don't want to have Entity

Framework and code first and all of

these things. No, you you absolutely

don't need to think about migrations and

things like that. You can push all of

that into the API, start using database

projects, and really kind of flow across

well, the entire prescriptive guidance

we have for interacting with SQL. And

so, it's a really neat tool to have in

your back pocket to pull out, add to

about any solution, save yourself a

significant budget of time and money.

And um and we love it as well. It's

worth at least pointing out this is the

engine inside of the Fabric API. This is

the engine inside of the Raven tools.

They I mean we have a lot of

dependencies across Microsoft. So this

isn't a science project that we're going

to forget about tomorrow. This is very

meaningful to us and the fact that we

can share it with the community to

reduce the friction for developers

interacting with SQL.

All the better and so what now with 2.0

it's even better than before. It's not

just shiny and new. Um we really have

introduced a lot of capabilities that

weren't there before and aka.ms

{slash} dab is how you get to our

repository or {slash} dab {slash} docs

is how you get to our documentation on

MS learn. So it's a it's a cool

opportunity to be able to talk about

data API builder. So thanks Anna. I'm

excited about 2.0. The the teams worked

really hard on it and frankly, it's

awesome.

>> Awesome. Well, it's it's great to learn

all about it. I know over the years

we've talked a little bit about data API

builder on the show, but I think it's

really I don't know if grown up is the

right word, but like met all of the

customer feedback asked or many of the

customer feedback asked to make this

really robust and great for production

types of scenarios. I think it's awesome

to see that. Thanks for sharing all

that. One question I have and then I

know you also have a demo is on the

right hand side kind of you have this

these people.

You have clients and you have agents.

Can you tell me a little bit how

somebody people are thinking about using

MCP servers and makes sense, but like

how do you think about clients versus an

agent using dab?

>> Yeah, that's a great point. If so a

client could be anything. You could have

a JSON application that runs in the

browser and never has a server or you

could have an actual server that is

using some sort of HTTP

class that's interacting with the

endpoint. So the nice thing is

since it's simply rest, and all you need

to do is interact with it like any other

API, and that is your database now. And

if you are an agent, so that means to

say if if you're an agent wrapped around

a model, and you're trying to interact

with it the database, there's no way for

an agent to interact with the database.

So now with MCP capabilities inside of

DAB, I could enable rest, I could enable

GraphQL, I could enable MCP, I can

enable all three at the same time, and I

can make it so that I have this type

this type of client, but I also have

this AI strategy that I'm trying to

implement. All three can be supported

from that same API container that I've

deployed. And so it's just a simple

container by the way, it could

Kubernetes, ACA, whatever it is you want

to deploy it as, and then we accept the

incoming off of whatever it is you're

using,

if it's intra or some sort of custom

OAuth provider, and then the outbound

off to SQL is whatever you decide as

well, and we support that, too. And so

yeah, you have those those three

different personas, right? You have like

maybe a mobile application would be

using GraphQL to be able to curate the

query being written. GraphQL is

incredibly powerful because it allows

you to write compound queries. So I

could say query this database in the

cloud and this database on prem, but

return it as a single payload to my

application, and and I can project only

these columns, and I can also do join

statements and filters as well. That's

really powerful for GraphQL, you see it

a lot in the mobile world because you

can tailor the payload. And then in

rest, it's just simple, right? It's just

a basically an endpoint for every table

view or stored procedure that you want

to expose, and then we run it for you

and then provide back the paginated

JSON. And so we have all kinds of

throttles inside, so if you're worried

about the size of your database, the

size of your data, the number of columns

you're providing back, you as the

developer have the control over that to

make sure that if these clients are

interacting with your data through a

rest endpoint, you can make sure they

are not destroying your database at the

same time. And so, there's a lot of

these special capabilities to make it

enterprise ready, not just like easy to

use, but also feature rich. So, a lot of

this is turned off by default, and then

as you're like, "Oh, I really wish we

could cash." You're like, "Oh, caching

equals true." And now all of a sudden

you have the caching capability inside

the container or outside in like Redis.

And so, there's a a lot of features that

you start digging into inside of DAB

that you realize these clients can be

extremely rich, and you don't have to

make hardly any modifications to Data

API Builder to get the kind of

capability and to meet the demand that

developers usually have for their

applications. It's pretty neat. I I

would say it this way. From an

architect's point of view, I would say,

if you are building custom CRUD APIs,

you better have a good reason at this

point. Because now that we're giving you

this, there's no language requirement,

there's no operating system requirement.

It's not SQL only. Like, you can drop

this anywhere, and all of a sudden you

have the ability to do like securely

interact with your back-end database in

a really robust way.

It should be able to honestly delete a

ton of code for most developers, and

make it so that developers starting out

don't have that sort of headwind and

friction to how do I get how do I

actually query the database, where I

think a lot of developers rely on ORMs

like Entity Framework to write the query

for them because they simply don't know

how. Um they can now rely on DAB and not

have the extra of how do I use Entity

Framework? How do I use all these other

ORMs? You don't need to. You can

actually just go directly to DAB as a

simple endpoint and get back some JSON.

So, that's the that's the idea. We want

these agents and clients to be um to do

as much as they can, but be as

not be very sophisticated at the same

time, so they can still interact with

SQL and get all the benefits from the

database.

>> Awesome. Cool. Yeah, that makes a ton of

sense. I'd love to take a quick look if

you have something to show us.

>> Yeah, 100%. Let me Let me show you

really quickly. So, I have the Omnibus

extension installed right now. And so, I

have a an an environment variable that

has my connection string. That's really

the only thing that's special here. And

so, if I say right click and init, so

that's initialize the JSON file,

it will pop up the a question for me.

Whoop, I just clicked off by mistake.

It'll pop up a question for me to reuse

that

connection string. And it's kind of nice

because we have a cross-platform CLI you

can use. And if you're wondering like,

"Man, how do I use that cross-platform

CLI?"

This extension inside VS Code really

helps because it runs all those commands

and then you can just kind of review

them and see, "Oh, I I start with dab

init." That initializes the file. Here's

how I pass in the connection string. And

then there are these extra pieces of

whether or not I want to this to be

production mode or if I want this to be

developer mode. And all of the defaults

that make sense to you probably are in

this extension and then you can go in

and tweak it as well. And once it's

built, by the way, I have This is the

the runtime setup that says, "Here I can

enable REST or I can enable GraphQL or I

can enable

MCP." And I keep saying or, but it's and

you can have all three of them at the

same time or you can turn them off and

off off and on depending on what your

requirements are. And then you can set

up your own custom

authentication as well as interact with

OpenTelemetry so that you can you can

push out all of your logs and activities

to a custom kind of single pane of glass

to be able to monitor your API

condition. So, a lot of power there

that's just really cool. And one one

other thing in this, let me just add, if

I add a table, I can add, for example, a

to-do table. This is pretty simple. I'll

add two, actually. And we have added

the ability not only to add not only to

add the um

tables and all of their columns, but

also descriptions to all of their

columns as well. Now that we have this

MCP capability, descriptions are really

valuable because we pass that along as

semantic data to the model.

And uh that's it. So, if I were to run

this today, and I'll just go ahead and

run it real quick, um I would just say

dab start, right? And it executes it,

connects it to the database, and now

it's running on um port 5,000 right here

for me. And what's cool about that is

one of the things I can interact with it

through swagger or through um nitro,

which is the new name for banana cake

pop, which is sort of swagger for

GraphQL. And I can also interact with

our health endpoint. And so, our health

endpoint in emits as JSON a whole block

of things around how everything is

performing inside your API. You can

query that on your own with your own

tool, and then we have this nice little

quick viewer just so you can see that

everything is running. So, this is me

interacting and testing to see just how

fast everything is going to um respond

from the to-dos table or from the

categories table using GraphQL. And then

here's the same thing inside of REST,

right? So, it's really cool to be able

to just get a snapshot and see how

things are going.

>> Nice.

>> And um and then I can also use this sort

of as a recipe for my app developers to

say, "Now that it's here,

go to town." And uh a lot of power in

your hands and um a lot of a lot of

responsibility, too, I suppose. But it's

a it's a neat thing. So, this is the

omnibus. O M N I B U S means all

contained. And it's about 10 uh data API

builder

uh oriented ex- um extensions inside VS

Code all combined into one. And so, it

makes it really easy to be able to do

things, including some of the more

sophisticated parts of DAB, like adding

relationships and enabling more

difficult like capabilities. It's really

neat.

>> Got it. Cool. Yeah, no, this is great.

It looks like it's easy to get started

and it seems like it's going to provide

and is providing a lot of value to

developers and agents

both across. Jerry, thanks so much for

coming on the show. I learned a lot. I

think our viewers did as well. If you're

watching this episode, go ahead give it

a like, leave us a comment, and let us

know what you're going to use DAB for

and we'll put some links in the

description for you to learn more. We

hope to see you next time on Data

Exposed.