Empezar con GraphQL en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre API for GraphQL en Fabric — la forma moderna de exponer datos de Fabric a aplicaciones. Los objetivos oficiales:

1. Explicar los componentes principales de GraphQL en Fabric y cómo funcionan.
2. Crear un API for GraphQL en Fabric.
3. Entender cómo gestionar relationships.
4. Consultar datos usando el editor.

Peso en el examen DP-700

GraphQL aparece principalmente en el Dominio 1 (implementar y gestionar):

Definición

GraphQL es un query language para APIs que permite a las aplicaciones pedir exactamente los datos que necesitan. Creado por Facebook en 2012, open-sourced en 2015. Es el estándar moderno para APIs.

Los 4 beneficios clave

1. Strong type system — describe claramente la data disponible.
2. Precise data fetching — evita el over-fetching pidiendo campos específicos.
3. Backward compatibility — actualizaciones fáciles sin romper el código existente.
4. Rich tooling — ecosistema enorme de developer tools.

Estructura básica de una query

query {
  productModels {
    items {
      ProductModelID
      Name
      ModifiedDate
    }
  }
}

Se lee: "de productModels, quiero items con solo ProductModelID, Name y ModifiedDate".

Sin GraphQL, quizás tendrías que llamar a /api/productmodels y recibirías 20 campos, aunque solo necesites 3.

Los problemas típicos sin GraphQL

Sin GraphQL, exponer data de Fabric a apps típicamente requiere:

A) Direct database connections

• Las apps conectan directo con SQL drivers (ODBC, JDBC).
• Acopla fuertemente el código a la BBDD.
• Los cambios de schema rompen las apps.
• Gestionar credenciales y drivers en cada app.
• SQL queries embebidas en el código = difíciles de testear.

B) Custom REST APIs

• Construir y mantener backend services (ASP.NET, Node.js).
• Controller code, routing, data access layer.
• API versioning (v1, v2, v3) cuando cambia el schema.
• Over-fetching (traer 30 campos cuando quieres 3).
• Under-fetching (múltiples round trips para data relacionada → problema N+1).

Cómo GraphQL lo resuelve todo

Fabric API for GraphQL:

1. ✅ No hace falta código backend — Fabric autogenera schema, resolvers y endpoint.
2. ✅ Pides exactamente lo que necesitas — campos específicos, sin over-fetching.
3. ✅ Traes data relacionada en 1 request — recorriendo relationships (sin problema N+1).
4. ✅ Schema evolution sin breaking changes — añades campos sin afectar a las queries existentes.
5. ✅ Type safety y self-documenting — schema con introspección integrada.
6. ✅ Acceso unificado a múltiples sources — query cross-source con un solo endpoint.

Comparativa rápida

Definición

Microsoft Fabric API for GraphQL = managed service que permite crear un GraphQL API en segundos sobre tus data sources de Fabric.

Por qué es especial

• 🚀 Generación automática de schema: Fabric mira tus tablas y genera el GraphQL schema automáticamente.
• 🔧 Resolvers automáticos: no escribes código, Fabric los crea.
• ⚡ Listo en minutos: setup completo en pocos minutos.
• 🎯 Sin setup de infraestructura: es SaaS.
• 🌐 Endpoint unificado: una sola URL para múltiples data sources.

Quién debería usar API for GraphQL

1. Application developers — apps web/mobile que consumen data de Fabric.
2. Data engineers — exponer data de Fabric a apps downstream sin backend custom.
3. Integration developers — conectar Fabric a apps custom y workflows automatizados.
4. BI developers — apps de analytics custom que complementan Power BI.
5. Data scientists — exponer data de Fabric e insights de ML vía APIs programáticas.

Proceso end-to-end

Exponer data sources en un item GraphQL = minutos vía el Fabric portal:

1. Crear un item GraphQL API en tu workspace de Fabric.
2. Conectar tus data sources — lakehouse, warehouse, database.
3. Elegir qué objects exponer — tables, views, stored procedures.
4. Definir relationships (opcional) — para nested queries.
5. Configurar permisos — control de acceso.

Una vez configurado, Fabric autogenera el GraphQL schema, crea los resolvers necesarios, te da un endpoint URL y el API queda listo para aceptar queries — sin deployment ni infra.

Tabla completa

⚠️ Requisito: Primary Key

Muy importante: cuando trabajas con warehouses y SQL Databases, debes definir una primary key para que las mutations se generen automáticamente. Sin primary key = no puedes hacer INSERT/UPDATE/DELETE vía GraphQL en ese objeto.

Los 2 tipos de operaciones

Fabric API for GraphQL soporta 2 tipos de operaciones:

A) Queries (read) 📖

• Recuperan data de tus sources.
• Ideales para operaciones read-only.
• Relevantes para los SQL Analytics Endpoints (que son inherentemente read-only).

B) Mutations (write) ✏️

• Modifican data: INSERT, UPDATE, DELETE.
• Adecuadas para operaciones de escritura.
• Requieren primary key en el objeto.

Otros tipos (NO soportados)

El estándar GraphQL tiene además subscriptions (push en tiempo real). NO están soportadas en Fabric API for GraphQL. Solo queries y mutations.

Auto-generation

Cuando expones un objeto (table, view), Fabric genera automáticamente:

Queries:

• <tableName> (listar todo)
• <tableName>(filter: ...) (con filtros)

Mutations (si hay primary key):

• create<TableName> (INSERT)
• update<TableName> (UPDATE)
• delete<TableName> (DELETE)

Cero código necesario. Fabric lo hace todo.

¿Qué es un GraphQL schema?

Un GraphQL schema es esencial para definir los tipos de data que se pueden consultar o mutar y cómo se relacionan entre sí. Provee una manera clara y concisa de describir las capacidades de un API.

Object types

Los object types representan una data entity en el schema: organizan data relacionada y definen los fields que se pueden consultar en cada type.

Analogía SQL: object types = tablas SQL.

type Product {
  ProductID: Int
  Name: String
  Color: String
  ListPrice: Float
}

Fields

Los fields especifican la data que se puede consultar en un object type. Pueden ser scalar values (Int, String, Float, Boolean) u otros object types, y pueden incluir argumentos para filtrar o modificar la data.

Analogía SQL: fields = columnas SQL.

Tabla comparativa

Schema autogenerado

No escribes el schema a mano. Fabric inspecciona tus tablas, detecta columnas y tipos, y genera el GraphQL schema automáticamente. Puedes personalizarlo después (enable/disable operations, añadir relationships, ocultar fields).

Este es un tema muy examinable. Vamos a fondo.

Los 2 modos

Fabric API for GraphQL soporta 2 modos de autenticación para conectar al data source:

A) Single Sign-On (SSO) 👤

• El usuario autenticado de la app que llama al GraphQL API debe tener:
  • Execute permissions en el GraphQL API.
  • Read/Write permissions en el data source.
• Cada usuario usa sus propias credenciales.

B) Saved credentials 💾

• Se guarda una credencial única para el API.
• Los usuarios NO necesitan acceso directo al data source.
• El API usa la saved credential para todos.

🎯 Diferencia clave

Cuándo cada uno

SSO ✅ cuando necesitas RLS y CLS por usuario real, auditoría granular por usuario, cada usuario tiene distinto acceso, el compliance requiere identificación individual, o todos los usuarios tienen acceso al workspace de Fabric.

Saved credentials ✅ cuando los usuarios no deben tener acceso al data source, la app expone data a usuarios externos (fuera del tenant), buscas simplicidad de gestión, o es obligatorio — como al exponer Azure SQL Database vía GraphQL (los usuarios no tienen credenciales para Azure SQL).

Workspace shortcut

Alternativa práctica para SSO: añadir al usuario como workspace member con rol Contributor en el workspace donde viven el API y el data source. Le da los permisos requeridos a ambos items desde un solo sitio.

UPN vs SPN

Puedes usar User Principal Names (UPNs) o Service Principal Names (SPNs) para conectar al API, tanto con SSO como con saved credentials.

Prerequisitos

Permisos del usuario: ser miembro del workspace de Fabric donde crearás el API, con al menos rol Contributor (o superior: Admin, Member).

Setup organizacional: el admin o capacity admin ha habilitado el tenant setting "Users can create Fabric items", y el workspace está respaldado por Fabric capacity (Premium, Trial o Fabric).

Data source access (para pasos posteriores): read permissions en los data sources a exponer, concedidos vía workspace membership o permisos directos al data source.

Pasos para crear

Opción A: desde el workspace

1. Cualquier workspace → New item.
2. Se abre el panel → Develop data → API for GraphQL.

Opción B: desde el home del Fabric portal

1. Data Engineering en la lista de workloads.
2. API for GraphQL.

En ambas opciones: introducir un nombre y seleccionar Create → API creado y totalmente funcional.

Conectar un data source

1. Bajo Add data to the API for GraphQL → seleccionar Select data source.
2. Aparece el diálogo Choose connectivity option.
3. Elegir: SSO o Saved credentials.
4. Aparece el OneLake catalog con los data sources disponibles.
5. Filtrar por tipo o buscar por palabra clave.
6. Seleccionar el data source → Connect.
7. Si es saved credentials y no existe una, se te pide crearla.
8. Página Choose data: seleccionar qué objects exponer (tables, views, procs).
9. Load → schema generado y objects expuestos.

Qué se genera automáticamente

Una vez cargas los datos, el motor GraphQL crea automáticamente las queries para cada object y las mutations para cada object (si tiene primary key). Listo para usar inmediatamente.

Feature

Puedes habilitar o deshabilitar queries y mutations específicas dentro del GraphQL schema, dando control fino sobre el acceso y uso del API. Esto significa que puedes gestionar las funcionalidades del API sin cambiar código ni redeployar.

Casos de uso

• Desactivación temporal de funcionalidades por mantenimiento, seguridad o performance.
• Controlar las operaciones del API según roles de usuario u otros criterios.
• Read-only mode: desactivar todas las mutations temporalmente.
• Exposición selectiva: tabla expuesta pero solo con SELECT (sin INSERT/UPDATE/DELETE).

Ejemplo

Tabla ProductModel de AdventureWorksLT expuesta. El motor genera automáticamente queries y mutations para insert, update y delete. Tú decides:

• ✅ Mantener la query productModels habilitada.
• ✅ Mantener la mutation createProductModel habilitada.
• ❌ Deshabilitar la mutation deleteProductModel (por seguridad).
• ❌ Deshabilitar la mutation updateProductModel temporalmente.

Cómo cambiarlo

Desde el GraphQL editor → schema explorer → property panel → toggle enable/disable. Los cambios son instantáneos, sin redeploy.

GraphQL soporta relationships entre types, permitiendo nested queries muy potentes. Fabric API for GraphQL soporta los 3 tipos:

One-to-one (1:1)

Cada instancia de un type está asociada con una única instancia de otro type. Ejemplo: el type User tiene una relación 1:1 con el type Profile. Cada user tiene exactamente un profile.

query {
  users {
    items {
      id
      name
      profile {
        bio
        avatar
      }
    }
  }
}

One-to-many (1:N)

Una única instancia de un type asociada con múltiples instancias de otro type. Ejemplo: el type User tiene una relación 1:N con el type Post. Un user puede tener múltiples posts.

query {
  users {
    items {
      id
      name
      posts {
        title
        publishedDate
      }
    }
  }
}

Many-to-many (N:M)

Múltiples instancias de un type asociadas con múltiples instancias de otro type. Ejemplo: Student tiene una relación N:M con Course. Cada student puede matricularse en varios courses, y cada course puede tener varios students.

query {
  students {
    items {
      id
      name
      enrolledCourses {
        title
        instructor
      }
    }
  }
}

Por qué son poderosas

Sin relationships: cada query trae un solo type, hay múltiples round trips para data relacionada y el cliente tiene que hacer los joins en su código.

Con relationships: modelos de datos ricos e interconectados, queries eficientes desde un solo request, y el cliente recibe una estructura jerárquica lista para usar.

Cómo definirlas en Fabric

Desde el GraphQL editor:

1. Schema explorer.
2. Click en un type → New relationship.
3. Configurar: type destino, cardinalidad (1:1, 1:N, N:M) y foreign key column.
4. Save → schema actualizado.

Cómo acceder

Navegar al item API for GraphQL en Fabric → buscar la opción Query (abajo a la izquierda) → seleccionar. Se abre el editor donde puedes construir y probar queries y mutations.

Los 4 paneles

1. Schema explorer 📚 — visualizar rápidamente los types y fields disponibles, ver las queries y mutations definidas en el API, navegar la estructura y modificarla (enable/disable operations, añadir relationships).

2. Run panel 🏃 — interfaz para ejecutar código y ver resultados en tiempo real. Test y debug de operaciones GraphQL.

3. Query variables panel 🔧 — pasar parámetros como variables a queries o mutations. Igual que en cualquier lenguaje: declarar variables con nombre para acceder a su valor.

4. Results panel 📊 — muestra el output de las queries/mutations ejecutadas, para verificar y analizar los resultados.

Auto-complete y validation

El editor tiene IntelliSense basado en el schema, syntax highlighting, validación en tiempo real y sugerencias de los fields disponibles.

Integración con Copilot

Copilot también puede ayudar con las queries GraphQL si está habilitado. Genera queries desde lenguaje natural, similar al Copilot de SQL Database.

Query básica

query {
  productModels {
    items {
      ProductModelID
      Name
      ModifiedDate
    }
  }
}

Traducción: dame de productModels todos los items, con los fields ProductModelID, Name y ModifiedDate.

Query con filter

query {
  productModels(filter: {Name: {eq: "Mountain-100"}}) {
    items {
      ProductModelID
      Name
      ModifiedDate
    }
  }
}

Traducción: dame los productModels donde Name = "Mountain-100".

Filter operators comunes: eq (equal), neq (not equal), gt, gte, lt, lte (greater/less), contains, startsWith y endsWith.

Resultado esperado

{
  "data": {
    "productModels": {
      "items": [
        {
          "ProductModelID": 19,
          "Name": "Mountain-100",
          "rowguid": "fca0665b-b956-489a-a5ec-6f0b4aa14d02",
          "ModifiedDate": "2005-06-01T00:00:00.000Z"
        }
      ]
    }
  }
}

Query con nested (relationships)

query {
  customers {
    items {
      customerID
      firstName
      lastName
      orders {
        items {
          orderID
          orderDate
          totalAmount
        }
      }
    }
  }
}

Una sola query devuelve los customers con sus orders anidadas. Sin GraphQL, esto serían N+1 llamadas.

Query con variables

query GetProduct($productName: String!) {
  productModels(filter: {Name: {eq: $productName}}) {
    items {
      ProductModelID
      Name
    }
  }
}

En el Query variables panel:

{
  "productName": "Mountain-100"
}

Ventaja: puedes reutilizar la query cambiando solo la variable.

INSERT (create)

mutation MyMutation {
  createProduct(
    name: "Mountain Bike",
    productNumber: "BK-M68B-38",
    color: "Black",
    standardCost: 500.00,
    listPrice: 800.00
  ) {
    productID
    name
    productNumber
    color
    standardCost
    listPrice
  }
}

Traducción: crea un nuevo product con estos valores. Devuelve los fields del producto creado (incluyendo el ID generado).

Resultado esperado:

{
  "data": {
    "createProduct": {
      "productID": "1234",
      "name": "Mountain Bike",
      "productNumber": "BK-M68B-38",
      "color": "Black",
      "standardCost": 500.00,
      "listPrice": 800.00
    }
  }
}

UPDATE

mutation {
  updateProduct(
    productID: 1234,
    listPrice: 850.00
  ) {
    productID
    listPrice
  }
}

Actualiza el listPrice del product con ID 1234.

DELETE

mutation {
  deleteProduct(productID: 1234) {
    productID
  }
}

Borra el product y devuelve su ID (confirmando el borrado).

Feature clave

Uno de los beneficios clave de GraphQL en Fabric: la capacidad de exponer múltiples data sources — lakehouses, warehouses, databases — a través de un único endpoint de API unificado.

Esto significa que las apps pueden recuperar data de distintas sources en una sola query GraphQL, eliminando la necesidad de conectar a múltiples APIs por separado.

Cómo funciona

Cuando lanzas una query GraphQL que abarca múltiples data sources, el API:

1. Distribuye automáticamente requests individuales a cada data source en paralelo.
2. Combina los resultados en una única respuesta.

Los 3 beneficios

1. Reduce round trips: 1 request en vez de múltiples llamadas secuenciales.
2. Mejora la performance: ejecución paralela = tiempos de respuesta más rápidos.
3. Simplifica el código cliente: una única interfaz de API independientemente de dónde viva la data.

Ejemplo real

Escenario: un dashboard que muestra info de customers e inventario de productos. La customer data está en el warehouse ContosoSales y el inventario en el lakehouse ContosoInventory.

Sin multi-source: 2 llamadas al API, 2 conexiones y combinar la data en el código de la app.

Con Fabric multi-source:

query {
  customers(first: 1) {
    items {
      FirstName
      LastName
    }
  }
  inventories(first: 1) {
    items {
      Name
    }
  }
}

Un solo request, dos sources. Response:

{
  "data": {
    "customers": {
      "items": [
        {
          "FirstName": "Orlando",
          "LastName": "Gee"
        }
      ]
    },
    "inventories": {
      "items": [
        {
          "Name": "AWC Logo Cap"
        }
      ]
    }
  }
}

Workaround para "joins" cross-source

Si necesitas "joinar" data de 2 sources: consulta ambas en el mismo request (paralelo, rápido) y haz el merge client-side por foreign key. No es un JOIN nativo, pero sirve para muchos casos.

Feature

Además de tablas y views, Fabric API for GraphQL puede exponer stored procedures como operaciones GraphQL.

Por qué

Los resolvers son componentes GraphQL que proveen la business logic para resolver fields y realizar operaciones con la data.

Generación automática: Fabric autogenera los resolvers cuando adjuntas un data source o expones nuevos objects.

Limitación de personalización: actualmente no puedes personalizar los resolvers directamente.

Workaround: para business logic personalizada, crea un stored procedure en el data source y exponlo en el GraphQL API.

Casos de uso

Cuando necesitas lógica que no es un CRUD trivial: business rules complejas, agregaciones custom, operaciones multi-tabla transaccionales, validación de datos compleja y cálculos derivados.

Ejemplo mental

Stored procedure en el warehouse:

CREATE PROCEDURE dbo.usp_CalculateCustomerLifetimeValue
    @CustomerID INT
AS
BEGIN
    -- Lógica compleja de cálculo
    SELECT
        @CustomerID AS CustomerID,
        SUM(o.TotalAmount) * 1.15 AS LTV,
        COUNT(o.OrderID) AS OrderCount,
        MAX(o.OrderDate) AS LastOrderDate
    FROM Orders o
    WHERE o.CustomerID = @CustomerID
    -- Más lógica...
END;

Expuesto en GraphQL:

query {
  calculateCustomerLifetimeValue(customerID: 123) {
    CustomerID
    LTV
    OrderCount
    LastOrderDate
  }
}

Client-side, una llamada GraphQL. Server-side, un stored proc con toda la business logic.

Schema autogenerado

Fabric API for GraphQL genera automáticamente un schema que define la estructura de tu API basándose en los data sources conectados. El schema, escrito en GraphQL Schema Definition Language (SDL), describe todos los types, fields, queries y mutations disponibles.

Los 2 tools

A) Schema view: vista read-only, basada en texto de tu GraphQL schema completo. Para ver la definición completa y copiarla como referencia.

B) Schema explorer: en el panel izquierdo. Para navegar, inspeccionar y modificar los objects expuestos vía API: enable/disable de operaciones y añadir relationships.

Ejemplo de SDL

type Product {
  ProductID: Int!
  Name: String!
  Color: String
  ListPrice: Float
  StandardCost: Float
  ModifiedDate: DateTime
}

type Query {
  products(filter: ProductFilterInput, first: Int, after: String): ProductConnection
  productModels(filter: ProductModelFilterInput): ProductModelConnection
}

type Mutation {
  createProduct(name: String!, listPrice: Float!, ...): Product
  updateProduct(productID: Int!, listPrice: Float): Product
  deleteProduct(productID: Int!): Product
}

Quién usa el schema view

• Data engineers configurando qué objects exponer.
• Application developers descubriendo los data types y relationships disponibles antes de escribir queries.
• Fabric workspace contributors entendiendo y gestionando la estructura de acceso a datos.
• BI developers revisando relationships al construir apps de analytics custom.

Los 3 datos necesarios

Para conectar una app a un GraphQL API en Fabric necesitas:

1. Client ID (de tu app registration de Entra ID).
2. Tenant ID (del Entra ID de tu organización).
3. GraphQL endpoint address (de Fabric).

Obtener el endpoint

La opción Copy endpoint de la toolbar del item API te da el endpoint URI. Ejemplo:

https://00001111-aaaa-2222-bbbb-3333cccc4444.z55.dailygraphql.fabric.microsoft.com/v1/workspaces/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/graphqlapis/aaaaaaaa-bbbb-cccc-1111-222222222222/graphql

Ejemplo Python

from azure.identity import InteractiveBrowserCredential
import requests
import json

# 1. Get access token
app = InteractiveBrowserCredential()
scp = 'https://analysis.windows.net/powerbi/api/user_impersonation'
result = app.get_token(scp)

if not result.token:
    print('Error:', "Could not get access token")

# 2. Prepare headers
headers = {
    'Authorization': f'Bearer {result.token}',
    'Content-Type': 'application/json'
}

# 3. Endpoint del API
endpoint = 'https://<...>.dailygraphql.fabric.microsoft.com/v1/workspaces/<...>/graphqlapis/<...>/graphql'

# 4. Query GraphQL
query = """
    query {
        products {
            items {
                ProductID
                Name
            }
        }
        salesOrderDetails {
            items {
                SalesOrderID
                OrderQty
                UnitPrice
            }
        }
    }
"""

# 5. Ejecutar
try:
    response = requests.post(endpoint, json={'query': query}, headers=headers)
    response.raise_for_status()
    data = response.json()
    print(json.dumps(data, indent=4))
except Exception as error:
    print(f"Query failed with error: {error}")

Nota: el ejemplo consulta múltiples data sources en un solo request.

Auth methods

Para user principals: Interactive (browser-based, para apps de escritorio) y Device code (para CLI/headless).

Para service principals: Client secret, Certificate y Managed Identity (si es un workload de Azure).

Requisito obligatorio

API for GraphQL requiere que las aplicaciones cliente usen Microsoft Entra ID para autenticarse. Tu app cliente debe estar registrada y configurada correctamente para ejecutar llamadas al API contra Fabric.

Permisos requeridos

La app registrada en Microsoft Entra ID requiere los API permissions GraphQLApi.Execute.All para el servicio Power BI.

Setup steps (resumen)

1. Ir al portal de Microsoft Entra ID.
2. App registrations → New registration.
3. Nombre y redirect URIs.
4. API permissions → Add → Power BI Service → GraphQLApi.Execute.All.
5. Admin consent (si aplica).
6. Copiar el Client ID y el Tenant ID.
7. Certificates & secrets → nuevo client secret (para service principals).

Este setup es estándar de Azure/Entra ID, no específico de Fabric.

Feature

Puedes generar código automáticamente para tu aplicación seleccionando Generate code en la toolbar del item API dentro del GraphQL designer.

Beneficio

Esta capability es útil para verificar que las llamadas al API funcionan como esperas, obtener código de partida para tu app, ver la sintaxis exacta para tu lenguaje y comprobar que la data se recupera y procesa correctamente.

Lenguajes soportados

Habitualmente: Python (con requests), JavaScript / TypeScript (con fetch o Apollo Client), C# (con HttpClient) y Java (con HttpClient o clientes GraphQL específicos).

Copy-paste-run

El código generado incluye el setup de autenticación, la configuración de headers, la URL del endpoint, la query (o mutation) y un error handling básico. Listo para ejecutar con mínimas modificaciones.

Nueva integración

Feature moderna: construir un GraphQL MCP server local para AI agents. MCP = Model Context Protocol, el protocolo de Anthropic para que los AI agents (como Claude) accedan a datos y herramientas externas.

Cómo integra con Fabric

Puedes configurar un GraphQL MCP server local que conecta a tu Fabric GraphQL API. Los AI agents (Claude Desktop, otros) pueden usar el MCP server como tool, y así consultar tus datos de Fabric en lenguaje natural.

Casos de uso

• Chat con tus datos: "¿Cuáles fueron los top 5 productos vendidos el mes pasado?".
• Análisis conversacional: el AI agent explora tu warehouse.
• Insights guiados por IA: agents que generan queries a partir de preguntas de negocio.
• Reporting automatizado: agents periódicos que analizan y reportan.

Configuración

Tutorial oficial: Build a local GraphQL MCP server for AI agents. Implica:

1. Crear el GraphQL API en Fabric.
2. Montar el MCP server local (Python/Node.js).
3. Configurar la conexión al endpoint GraphQL de Fabric.
4. Registrar el MCP server en tu cliente de AI agent.

Casos ideales

A) Web/mobile apps con data de Fabric: la app consume data del warehouse o lakehouse, necesita queries flexibles y tiene múltiples vistas con distintas necesidades de datos.

B) Aplicaciones que cruzan múltiples data sources: data en varios warehouses/lakehouses, donde un endpoint unificado simplifica la arquitectura.

C) Apps de analytics custom que complementan Power BI: Power BI para dashboards estándar y una app custom para casos específicos con GraphQL.

D) Integraciones y automatizaciones: herramientas de workflow que necesitan data de Fabric, scripts, cron jobs.

E) AI agents y Copilot custom: MCP server sobre GraphQL, con agents que consumen data de Fabric.

F) Data APIs para partners externos: exponer un subset de la data de Fabric a partners, con saved credentials y control granular del schema.

Cuándo NO usar GraphQL

• A) Usuarios que solo usan reports de Power BI: Direct Lake es más simple y perfecto para BI.
• B) Analytics batch masivo: los notebooks o pipelines son mejores.
• C) Streaming en tiempo real: Eventstream + Eventhouse.
• D) ETL interno de data warehousing: pipelines de Data Factory.
• E) Apps que ya funcionan con ODBC/JDBC: la migración a GraphQL debe justificar el esfuerzo.

Combinación con otros items

Muy común la coexistencia: el Warehouse guarda la data, el semantic model + Power BI cubren el BI estándar, el API for GraphQL sirve a las apps custom y los notebooks al data science. Todo desde la misma data subyacente en OneLake.

• Trampa 1: "GraphQL soporta subscriptions en Fabric" ❌ Solo queries y mutations. Las subscriptions (push en tiempo real) NO están soportadas.
• Trampa 2: "Todas las tablas tienen mutations automáticamente" ❌ Las mutations requieren primary key en warehouses y SQL Databases. Sin PK → solo queries.
• Trampa 3: "Puedo mezclar SSO y saved credentials en el mismo API" ❌ NO se pueden mezclar. Es una decisión por API, y se aplica a todos los data sources añadidos después.
• Trampa 4: "Puedo crear relationships cross-data-source" ❌ Las relationships funcionan solo dentro del mismo data source. Las multi-source queries son llamadas paralelas, no joins.
• Trampa 5: "Las multi-source queries son transaccionales" ❌ Cada request es independiente, NO hay transacción que abarque varias sources.
• Trampa 6: "Puedo personalizar los resolvers directamente" ❌ NO. Fabric los genera automáticamente. Para business logic custom → stored procedures en el data source, expuestos vía GraphQL.
• Trampa 7: "SSO requiere workspace membership" ❌ Puedes usar SSO con permisos directos al data source, o con workspace membership (rol Contributor) como atajo.
• Trampa 8: "API for GraphQL no requiere Entra ID" ❌ Requiere autenticación con Microsoft Entra ID SIEMPRE. Las apps cliente deben estar registradas.
• Trampa 9: "El Lakehouse expone mutations vía GraphQL" ❌ El Lakehouse expone data vía SQL Analytics Endpoint, que es read-only. Solo queries, no mutations.
• Trampa 10: "GraphQL siempre es más lento que REST" ❌ Al contrario: evita el over-fetching y el under-fetching, así que típicamente es más eficiente en casos complejos.
• Trampa 11: "Multi-source es un JOIN nativo" ❌ Son llamadas paralelas combinadas en la response. Merge client-side si necesitas semántica de join.
• Trampa 12: "Saved credentials expone TODOS los datos a TODOS los usuarios" ❌ Los usuarios siguen necesitando Execute permissions en el API. Solo se comparte el acceso al data source subyacente.
• Trampa 13: "Puedo cambiar el schema manualmente" ❌ Fabric autogenera el schema. Puedes hacer enable/disable de operaciones y añadir relationships, pero no modificar types.
• Trampa 14: "El schema view permite editar" ❌ El schema view es read-only. Para modificar usas el schema explorer (paneles y toggles).
• Trampa 15: "Las operaciones deshabilitadas siguen ejecutándose en silencio" ❌ Los intentos sobre operaciones deshabilitadas devuelven error. No es un fallo silencioso.
• Trampa 16: "API for GraphQL sirve para data streaming" ❌ Es para patrones request/response. Para streaming usa Eventstream.
• Trampa 17: "Puedo exponer stored procedures de cualquier data source" ✅ Sí, para business logic custom. Los stored procs expuestos aparecen como operaciones en el schema.
• Trampa 18: "Los AI agents necesitan mi login de Fabric para GraphQL" ✅ MCP server + service principal + Entra ID = AI agents autenticados. Muy flexible.

GraphQL vs REST

Queries vs Mutations en Fabric GraphQL

Data sources soportados

SSO vs Saved credentials

Relationships (dentro de 1 source)

Multi-source limitations

Los 4 paneles del editor

Componentes básicos del schema

Custom business logic

• Módulo Learn: get-started-with-graphql-microsoft-fabric
• What is Microsoft Fabric API for GraphQL?: api-graphql-overview
• Create an API for GraphQL in Fabric: get-started-api-graphql
• GraphQL editor: api-graphql-editor
• Query multiple data sources: multiple-data-sources-graphql
• Connect applications: connect-apps-api-graphql
• Stored procedures in GraphQL: api-graphql-stored-procedures
• Schema view y explorer: graphql-schema-view
• FAQ: graphql-faq
• Build local GraphQL MCP server for AI agents: api-graphql-local-model-context-protocol
• Data API builder GraphQL: data-api-builder/graphql
• Create Entra app: create-entra-app