What API for GraphQL Is and Why It Matters#
API for GraphQL automatically generates a GraphQL schema, resolvers, and a live endpoint from the data sources you connect to it, so no custom backend code is required to expose that data to applications [S1]. Point it at a Warehouse or a Lakehouse, pick the tables you want, and Fabric builds the query surface for you — there is no service to write, package, or deploy.
The payoff shows up on the client side. A single GraphQL query can request only the specific fields a caller needs and traverse defined relationships in one round trip, which sidesteps both the over-fetching that plain REST responses are prone to and the N+1 query pattern that shows up when a client has to make a follow-up call per related record [S1]. For a mobile app that only needs a customer's name and their last three orders, that is the difference between one call and a cascade of them.
A single query can request only the specific fields a client needs and traverse defined relationships in one round trip, avoiding both over-fetching and the N+1 query pattern common to REST [S1].
This matters because GraphQL API is one of the newer, less-worn entry points into Fabric data. Where teams previously chose between wiring a SQL driver into every consuming app or hand-rolling a REST layer to sit in front of it, API for GraphQL offers a third, configuration-driven path — one that is also, notably, being positioned as an access surface for AI agents, not only for human-facing applications [S1].
What It Connects To#
API for GraphQL isn't limited to a single Fabric item type. Supported data sources include Fabric Data Warehouse, Fabric SQL database, Fabric Lakehouse (via its SQL analytics endpoint), Azure SQL Database, and Fabric mirrored databases — which in turn cover Azure SQL DB, Azure SQL Managed Instance, Cosmos DB, Fabric SQL Database, Azure Databricks, Snowflake, and open mirrored databases, all accessed through their SQL analytics endpoints [S1].
That list has a common thread worth noticing: everything routes through a SQL analytics endpoint of some kind. A Lakehouse isn't queried through its Spark engine here — it's the SQL analytics endpoint sitting in front of the Delta tables that GraphQL talks to. The same is true of every mirrored source. Inference: this suggests API for GraphQL is architecturally a schema-and-resolver layer over SQL analytics endpoints across Fabric's item types, rather than a source-specific connector built per item — the claims establish the breadth of supported sources [S1] but don't document the endpoint-routing mechanism itself, so treat that framing as a reasonable read rather than a separately verified fact.
Setting one up#
Getting from zero to a queryable endpoint is a portal-driven workflow, not a deployment pipeline: create the GraphQL item, connect data sources, choose which tables, views, or stored procedures to expose, optionally model relationships between them, and configure access permissions — after which the endpoint is immediately queryable with no separate deployment step [S1].
There is no build-and-deploy cycle here. The moment the item is configured, the endpoint is live [S1].
The portal also ships a way to try it without leaving the browser: an interactive editor with a results pane, parameterized query and mutation support, and schema-aware Intellisense for building and testing queries against the generated schema [S1].
Modeling Relationships and Schema Evolution#
GraphQL items aren't limited to flat, single-table lookups. They support fan-out queries across multiple attached data sources at once and can model one-to-one, one-to-many, and many-to-many relationships between the entities they expose [S1]. That means a query can, for example, pull a warehouse fact table and a mirrored dimension table together in one traversal, provided the relationship has been modeled.
Schema change is where GraphQL's request-what-you-need shape pays off architecturally. Fabric's GraphQL schema evolution favors additive, non-breaking changes and field deprecation over issuing versioned endpoints — no v1, v2, v3 sprawl — because clients only ever receive the fields they explicitly request [S1]. Adding a field to the schema doesn't touch any client that doesn't ask for it.
Why this best practice matters#
Rule: design new fields as additive, and deprecate old ones explicitly rather than standing up a new endpoint version.
Why: because Fabric's GraphQL schema evolution model is built around additive change and clients only receive the fields they request, a new field can't break an existing client that never queries it [S1]. Versioned endpoints exist to solve a breaking-change problem that this request shape mostly avoids.
# Wrong: reacting to a schema change by minting a new endpoint
# /graphql/v1 -> /graphql/v2 (clients must migrate wholesale)
# Right: add the new field alongside the old one, then deprecate the old field
type Customer {
name: String!
loyaltyTier: String # existing field, unchanged
loyaltyTierV2: String # new field, added additively
legacyDiscountCode: String @deprecated(reason: "Use loyaltyTierV2 instead")
}
# Existing clients querying { name loyaltyTier } keep working unmodified;
# new clients opt into { name loyaltyTierV2 } when ready.
GraphQL as an Agent-Facing Surface#
API for GraphQL's audience isn't only human application developers anymore. Microsoft now documents a path to connect AI agents to Fabric data through the GraphQL endpoint using the Model Context Protocol (MCP), positioning the API as an agent-facing data access layer in addition to a human application API [S1].
That's a meaningful framing shift for architects: the same schema-and-resolver layer that serves a mobile app's data needs is being set up as the interface an AI agent uses to reach into Warehouse, Lakehouse, or mirrored-database data. A single GraphQL item, once modeled with sensible relationships and field-level access control, can plausibly serve both audiences without duplicating access logic.
Internals#
Architecture & design#
The architectural core of API for GraphQL is generation, not configuration of hand-written services: the schema, its resolvers, and the live endpoint are all produced automatically from whichever data sources are connected, which is precisely what removes the need for custom backend code [S1]. The item you create in the Fabric portal isn't a shell that you fill in with resolver logic — it's the finished artifact once sources, exposed tables/views/stored procedures, relationships, and permissions are configured [S1].
That generated layer sits uniformly over a wide set of backends — Warehouse, SQL database, Lakehouse SQL analytics endpoints, Azure SQL Database, and the full spread of mirrored-database types [S1] — which is what lets the same interactive editor, schema, and Intellisense experience work regardless of which of those sources is actually attached [S1].
How it works internally#
At query time, the field-selection model is what does the real work: because a client names only the fields and relationship traversals it needs, the generated resolvers can satisfy an arbitrarily shaped request in a single round trip rather than the client issuing a chain of follow-up calls per related record — the N+1 pattern that plain REST access commonly falls into [S1]. Fan-out queries extend that same mechanism across multiple attached data sources at once, following the one-to-one, one-to-many, and many-to-many relationships modeled on the item [S1].
Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as a Microsoft engineering blog or architecture deep-dive describing how Fabric's GraphQL resolvers actually translate a fan-out query into underlying SQL analytics endpoint calls (pushdown behavior, join strategy, query planning). Tracked in content/queue.md.
Performance characteristics#
The one verified operational-depth claim in scope here is monitoring, not a benchmark: Fabric exposes a built-in performance monitoring dashboard with request logging for GraphQL API items, intended to track API usage and behavior over time [S1]. That gives teams a way to observe how an endpoint is actually being used and behaving in production, but no quantified latency, throughput, or scaling numbers are documented for the GraphQL API in the knowledge base yet.
Coming soon — quantified performance numbers (query latency, resolver overhead versus direct SQL, fan-out scaling behavior) aren't in the knowledge base yet. It needs an L4/L5 source such as a Microsoft engineering blog or benchmark writeup on Fabric GraphQL API performance. Tracked in content/queue.md.
Worked Example#
Consider a customer-facing mobile app team that needs a customer's profile plus their most recent orders, and a data platform team that wants to avoid maintaining a bespoke REST service just for this.
1. Connect the sources. The team creates a GraphQL item and connects it to a Fabric Warehouse holding Customers and a mirrored Azure SQL Database holding Orders, both reachable through their SQL analytics endpoints [S1].
2. Expose tables and model the relationship. They choose the Customers and Orders tables from the setup workflow and model a one-to-many relationship — one customer to many orders — directly in the portal, then configure access permissions before anything goes live [S1]:
# Illustrative shape of the auto-generated schema after modeling the relationship
type Customer {
id: ID!
name: String!
orders: [Order!]! # one-to-many relationship, modeled in the setup workflow
}
type Order {
id: ID!
placedAt: String!
total: Float!
}
Inference: this schema excerpt illustrates the shape the auto-generation would plausibly produce given a modeled one-to-many Customer-to-Order relationship [S1]; it is not a literal schema reproduced from a source.
3. The app fetches everything it needs in one round trip. Instead of one REST call for the customer and a follow-up call per order, the mobile app issues a single query naming only the fields it actually uses [S1]:
query RecentOrders($customerId: ID!) {
customer(id: $customerId) {
name
orders(last: 3) {
placedAt
total
}
}
}
4. The endpoint is live immediately. There is no build or deploy step to run — as soon as the sources, exposed tables, relationship, and permissions are configured, the query above is answerable [S1].
5. The platform team watches usage, not logs they built themselves. They rely on Fabric's built-in performance monitoring dashboard and request logging for the GraphQL item to see how the mobile app's query patterns behave over time, rather than instrumenting a custom service [S1].
6. Six months later, the team adds a loyalty field. Because Fabric's GraphQL schema evolution favors additive change, they add loyaltyTier to the Customer type without touching the existing RecentOrders query above — no version bump, no client migration required [S1].