In Short: The Service Layer You Did Not Have to Build
Every data team eventually gets the request: "can the app just call the data?" The traditional answer is a small service project - endpoints, models, auth, hosting - to put an API in front of the analytics platform. Fabric's API for GraphQL collapses that: pick tables from a lakehouse, warehouse, SQL database or mirrored source, and Fabric generates a typed GraphQL endpoint over them, with Entra authentication and the platform's permission model already attached.
For internal tools, data apps and agents that need governed data as context, it turns a fortnight of plumbing into an afternoon of configuration.
What It Actually Does
- Schema from your data: selected tables become GraphQL types; relationships you define become traversable connections
- Queries with selection: callers request exactly the fields they need, filtered and paginated, in one round trip
- Mutations where writes belong: writable sources (notably Fabric SQL databases) get insert, update and delete operations; analytical stores stay read-oriented
- Entra on the front door: authentication is Microsoft Entra, and data access follows the Fabric security model, so the API cannot see what its identity cannot
Under it all, the data stays in OneLake: the endpoint is a projection, not another copy.
The Use Cases That Fit
Internal data apps. The ops tool that shows customers, orders and status from the gold layer: previously an API project, now a GraphQL item plus a front end.
Agents needing governed context. Custom agents and Foundry builds fetch structured context through a typed contract instead of ad-hoc SQL - one endpoint to secure, one schema to reason about.
ISV and integration surfaces. Partners consuming your curated data get a contract that documents itself, rather than a shared SQL login and a prayer.
Prototypes that must not become debt. Because the endpoint is configuration, throwing it away costs nothing - a healthier prototyping loop than a bespoke service that quietly becomes production.
The Limits to Respect
It is a data API, not an application platform: business logic, orchestration and cross-system workflows still belong in real services or Power Platform. Latency is analytical-grade, excellent for tools and dashboards, not a promise for high-frequency transactional UIs. Public internet exposure should still sit behind API management with your own throttling and keys. And every request bills the capacity, so a wildly popular endpoint deserves the same consumption watch as any other workload.
Inside those lines, it is one of Fabric's quiet productivity wins: the gap between "we have the data" and "the app can use it" measured in hours.
Sources and Further Reading
Frequently asked
A Fabric item that exposes data from lakehouses, warehouses, SQL databases and mirrored sources as a typed GraphQL endpoint. You pick the tables, Fabric generates the schema with queries (and mutations for writable sources), and applications call one endpoint instead of you building a service layer.
Callers ask for exactly the fields and relationships they need in one request, and the schema is self-documenting and typed. For data-serving scenarios - dashboards, internal tools, agents fetching context - that shape fits better than hand-rolling REST endpoints per view.
Against writable sources such as Fabric SQL databases, generated mutations support inserts, updates and deletes. Against analytical stores like lakehouse tables via the SQL endpoint, access is read-oriented - which matches how analytical data should be consumed anyway.
Requests authenticate with Microsoft Entra, and access respects the Fabric permission model - the caller (or the connection identity) needs rights to the underlying data. It is not an anonymous public API gateway; internet-facing scenarios still belong behind your own API management.
Requests consume Fabric capacity units like other workloads. A dashboard polling every few seconds across thousands of users is a real load; an internal tool serving a team is a rounding error. Measure in the Capacity Metrics app once real traffic exists.
