Q&A
Simplifying API Creation with Data API Builder
Leonard Lobel breaks down how the Data API Builder allows developers to effortlessly expose database objects such as tables, views and stored procedures as fully functional APIs.
Developers often face the challenge of building APIs over complex databases, a time-consuming task that requires significant effort. Leonard Lobel, CTO of Sleek Technologies, is here to change that with the introduction of Data API Builder (DAB). In this exclusive Q&A, Lobel discusses how this innovative tool simplifies the creation of REST and GraphQL endpoints, saving developers valuable time while enhancing the flexibility and security of their applications.
In his fast approaching Live! 360 session, "Creating REST and GraphQL Database Endpoints with Data API Builder," Lobel will provide live demos showcasing how to integrate Data API Builder into real-world applications. Attendees will gain hands-on experience with both REST and GraphQL endpoints, as well as practical insights into optimizing performance and securing APIs with Microsoft Entra ID and role-based security.
Time is running out to make your plans to join us for Live! 360, taking place in Orlando, Fla. Nov 17-22. Register by Oct. 25 to take advantage of our early bird pricing and save $300!
Redmond: What inspired the development of the Data API Builder, and what key challenges does it aim to address?
Lobel: With developers repeatedly performing the same grunt work to build a basic API over the database, it makes sense to provide a framework that simplifies and streamlines the process. It can be very challenging to build out an API over all the objects in your database, while DAB (Data API Builder) does all the work for you, saving enormous amounts of valuable development time.
Can you provide a brief overview of how the Data API Builder simplifies the creation of REST and GraphQL endpoints?
The entire process is driven by a simple configuration file, where you list the entities (tables, views and/or stored procedures) that you wish DAB to expose as either REST or GraphQL endpoints.
What are the primary benefits of using Data API Builder for CRUD operations and stored procedure calls?
If you just need basic and direct (yet secured) access to tables for CRUD operations, DAB automatically generates those endpoints for you. Zero manual labor! But if you'd rather shield tables from the API, it's just as effortless to implement a stored procedure layer for controlled access (with business logic) and expose those stored procedures via the API.
How does Data API Builder support different types of databases, including SQL Server, Azure SQL, MySQL and Azure Cosmos DB?
For SQL Server, Azure SQL Database and MySQL, the experience is the same. DAB will create REST endpoints against all the entities you specify in the configuration file. It will also create GraphQL endpoints that automatically joins multiple related rows together to return an entire entity graph (rather than a single entity). For Azure Cosmos DB, the appeal is not as strong for two reasons. First, the database service already provides a native REST API that expose REST endpoints for CRUD operations against documents in a container. Second, since Cosmos DB is a NoSQL database, it uses a denormalized data model and doesn't support joins. Child entities are embedded (pre-joined) in the parent document, and so there is no inherent advantage in using GraphQL endpoints with Cosmos DB either.
What kind of feedback have you received from early adopters of Data API Builder?
Overall, the feedback has been extremely positive.
Are there any common pitfalls or best practices developers should be aware of when using Data API Builder?
Things to watch out for include misconfiguration of the data source, and incorrect role or permission settings. You also need to be careful to avoid poorly constructed queries (for example, over-fetching data) that can lead to performance issues, and to avoid overcomplicating the implementation with business logic. Best practices include organizing and maintaining separate configuration files for different environments, optimize your queries for performance (for example, use filters, and avoid fetching unnecessary data), apply the proper security, and leverage caching on the client and/or server, logging, and monitoring.
What should participants expect from your session, and what practical skills will they gain?
Expect to learn all about this framework. Also, since a great many developers are less familiar with GraphQL than REST, expect to learn the benefits of using GraphQL as an alternative to REST. You'll see extensive demos that start from scratch, and show CRUD operations, access to views, and stored procedure calls, all using both REST and GraphQL endpoints. You'll also learn how to secure your endpoints with Microsoft Entra ID role-level security, and how to integrate with row-level security (RLS) in SQL Server.
What resources can you point for attendees to learn more about Data API Builder and prepare for your session?
Check out the official documentation (with quickstarts) at: https://learn.microsoft.com/en-us/azure/data-api-builder/
Have a look at the source code and samples on GitHub at: https://github.com/Azure/data-api-builder