Cuando pensamos en Microsoft Fabric es bastante sencillo imaginar el recorrido de nuestros datos.
Los ingerimos, los transformamos, los almacenamos en un Lakehouse o un Warehouse, creamos nuestro modelo semántico y, finalmente, construimos informes que permitan analizarlos.
Es un camino que conocemos bastante bien. Pero hay situaciones en las que visualizar los datos no es suficiente. Imaginemos, por ejemplo, una aplicación interna para gestionar incidencias.
Queremos consultar las incidencias existentes, crear nuevas, asignarlas a una persona, cambiar su estado, consultar determinados indicadores y, quizás, combinar todo eso con información analítica que ya tenemos en Fabric.
Podemos empezar a resolver algunas de esas necesidades con diferentes herramientas, pero llega un momento en el que realmente lo que estamos construyendo es una aplicación.
Y aquí es donde aparecen las Fabric Apps. ¿Qué es una Fabric App?
Microsoft define Fabric Apps, actualmente en versión preliminar, como una capacidad basada en el SDK de Rayfin que permite crear aplicaciones orientadas a datos dentro de Microsoft Fabric utilizando un flujo de desarrollo unificado.
Dicho de una manera algo menos formal:
Fabric Apps nos permite desarrollar aplicaciones web utilizando Fabric también como plataforma para desplegar y proporcionar buena parte de los servicios que necesita nuestra aplicación.
Y esta segunda parte es importante.
No estamos hablando simplemente de alojar una página web dentro de Fabric.
Cuando desplegamos una Fabric App podemos tener diferentes piezas detrás: una base de datos SQL administrada, una API GraphQL, autenticación mediante Microsoft Entra ID y el alojamiento del contenido estático de nuestra aplicación. Fabric se encarga además del hosting, la red y el escalado de esos servicios.
Es decir, empezamos a hablar de algo bastante parecido a esto:
Frontend → API → lógica de acceso → base de datos
Pero con Fabric encargándose de buena parte de la infraestructura necesaria para que esas piezas funcionen. Y esto cambia bastante la conversación. ¿No creéis?
Aunque este sea un artículo introductorio, creo que merece la pena entender mínimamente qué ocurre por debajo. Dicho de otra forma, vamos a levantar el capó y ver que hay dentro.
Y dentro, una de las piezas centrales de Fabric Apps es Rayfin. Rayfin proporciona el SDK y la CLI que utilizamos para desarrollar y desplegar nuestras aplicaciones. Actualmente podemos crear un proyecto, modificarlo desde nuestro editor, probar nuestros cambios y posteriormente desplegarlo utilizando la CLI de Rayfin.
Por ejemplo, el despliegue completo de una aplicación se realiza mediante:
npx rayfin up
No hace falta memorizar el comando. Lo interesante es entender lo que ocurre cuando lo ejecutamos. Fabric analiza la configuración de nuestra aplicación y crea los servicios necesarios dentro del propio elemento Fabric App. Y aquí aparece otra idea interesante, una Fabric App no es simplemente un único objeto aislado. Al desplegarla, Fabric puede crear diferentes servicios hijos asociados a ella.
Entre ellos encontramos actualmente:
- una SQL Database en Fabric;
- el servicio de autenticación;
- el contenido estático correspondiente al frontend;
La aplicación dispone además de una URL de frontend y una URL para su backend. Por tanto, detrás de ese elemento que vemos en nuestro workspace hay bastante más de lo que parece a primera vista.
Otra característica importante de Fabric Apps es que el desarrollo gira alrededor de TypeScript. Y aquí encontramos probablemente una de las partes técnicamente más interesantes de todo el planteamiento. Podemos definir nuestro modelo de datos mediante clases TypeScript y decoradores.
Por ejemplo, conceptualmente podríamos definir una entidad que represente una tarea indicando que tiene:
- un identificador;
- un título;
- una descripción;
- una fecha;
- un estado.
Los decoradores permiten indicar qué clase representa una entidad y qué tipo de dato tiene cada una de sus propiedades.
A partir de esa definición, Rayfin puede generar diferentes elementos necesarios para nuestra aplicación. Entre ellos: el esquema de la base de datos, la configuración de la API GraphQL y los tipos utilizados posteriormente por el cliente.
Es decir, no estamos definiendo el modelo de datos por un lado, creando manualmente las tablas por otro y construyendo después cada endpoint de la API. El modelo definido en TypeScript se convierte en la base sobre la que se generan esas diferentes capas.
Esto no significa que la aplicación se construya sola. Seguimos desarrollando una aplicación y seguimos trabajando con código. Pero sí desaparece buena parte del código repetitivo que normalmente existiría entre el modelo de datos, la API y el cliente que consume esa API.
Fabric Apps genera una API GraphQL sobre nuestro modelo. GraphQL es el mecanismo que permite que el frontend consulte o modifique la información.
Por ejemplo, nuestra aplicación podría necesitar:
- recuperar las tareas pendientes;
- crear una nueva tarea;
- actualizar una existente;
- eliminar un registro.
Estas operaciones pueden realizarse a través de la API generada por Fabric Apps.
Además, el SDK proporciona RayfinClient, un cliente TypeScript tipado que permite trabajar con esas operaciones manteniendo información sobre los tipos que hemos definido en nuestro modelo.
El objetivo es que determinados errores puedan detectarse durante el desarrollo, antes incluso de que la petición llegue al backend. Aquí empieza a entenderse mejor eso de flujo de desarrollo unificado.
Definimos nuestro modelo una vez y esa definición termina teniendo impacto en diferentes capas de la aplicación.
Cuando nuestra aplicación necesita almacenamiento operacional (que no tiene por qué necesitarlo), Fabric Apps puede crear una SQL Database en Microsoft Fabric asociada a la aplicación. El esquema de esa base de datos se genera a partir del modelo que hemos definido mediante TypeScript.
Por ejemplo:
TypeScript àModelo de datos à SQL Database à GraphQL API à RayfinClient à Frontend
Creo que esta imagen mental ayuda bastante a entender cómo está planteada actualmente la arquitectura (por lo menos para mí… 😊 ) Hay además un detalle importante.
Microsoft recomienda que los cambios del esquema se gestionen desde el código y se desplieguen mediante Rayfin, no modificando manualmente la estructura de la base de datos desde el portal de Fabric. Es decir, el código pasa a ser la definición principal de la estructura de nuestra aplicación.
Por supuesto, si estamos construyendo aplicaciones empresariales necesitamos saber quién está utilizando nuestra aplicación y qué puede hacer.
En una Fabric App desplegada, la autenticación utiliza Fabric SSO mediante Microsoft Entra ID. El usuario accede utilizando su identidad de Fabric y la plataforma se encarga del proceso de autenticación y de la gestión de los tokens necesarios. Actualmente, en las aplicaciones desplegadas no se admiten otros proveedores de autenticación. Pero autenticación y autorización no son lo mismo.
Saber quién es Javier no significa automáticamente saber qué datos puede consultar Javier.
Para eso Fabric Apps permite definir permisos junto al propio modelo. Es posible definir permisos para crear, leer, modificar o eliminar información y establecer políticas que tengan en cuenta los claims del usuario autenticado.
Microsoft documenta incluso escenarios de autorización a nivel de fila, donde un usuario solamente puede acceder a los registros que le corresponden.
No voy a entrar mucho más aquí porque daría para otro artículo completo.
Pero la idea importante es que modelo de datos y seguridad pueden definirse dentro del mismo modelo de programación.
Hasta ahora hemos hablado mucho de base de datos, GraphQL, TypeScript y autenticación. Pero necesitamos también la parte que utilizará el usuario. Nuestra aplicación sigue siendo una aplicación web.
El frontend termina compilándose en los habituales recursos web —HTML, CSS y JavaScript— y Fabric Apps proporciona el alojamiento de ese contenido estático.
Cuando desplegamos la aplicación, esos recursos se publican y Fabric proporciona una URL desde la que acceder a ella. Por tanto, Fabric no nos obliga a construir nuestra interfaz como si fuera un informe de Power BI. Estamos desarrollando una aplicación web y tenemos mucha más libertad sobre cómo queremos que sea la experiencia del usuario. Y creo que aquí está una de las diferencias fundamentales.
Es fácil mirar todo esto desde nuestra experiencia con Power BI e intentar encontrar inmediatamente la comparación. Pero no son lo mismo. Power BI continúa siendo una pieza central cuando necesitamos crear experiencias de análisis mediante informes.
Fabric Apps aparece para escenarios en los que necesitamos una aplicación web más personalizada. De hecho, Microsoft explica que Fabric Apps complementa los informes de Power BI en aquellos escenarios en los que necesitamos mayor flexibilidad, iteraciones más rápidas o experiencias más adaptadas al usuario.
Un informe puede permitirnos analizar las ventas de nuestra compañía. Una Fabric App podría, por ejemplo, permitirnos consultar esas ventas y combinarlas dentro de una experiencia propia con otra funcionalidad desarrollada específicamente para nuestro proceso. Son necesidades diferentes. Y, en determinados escenarios, pueden complementarse.
Otro punto que me parece especialmente importante es que una Fabric App no necesita obligatoriamente estar conectada a un modelo semántico.
La plataforma general de Fabric Apps permite construir aplicaciones orientadas a datos utilizando su propio modelo, SQL Database, GraphQL, autenticación, etc.
Pero Microsoft proporciona además una plantilla específica denominada data app template para aquellos escenarios en los que queremos construir aplicaciones analíticas conectadas a un modelo semántico de Power BI.
Aquí sí entramos en un terreno especialmente conocido. La plantilla incluye capacidades preparadas para:
- autenticarse en Fabric;
- conectarse a un modelo semántico;
- ejecutar consultas DAX;
- y generar visualizaciones dentro de la aplicación.
Actualmente estas aplicaciones utilizan la Execute Queries REST API para consultar el modelo semántico y el usuario necesita permisos Read y Build sobre dicho modelo.
Por tanto, podríamos tener una aplicación web completamente personalizada utilizando detrás un modelo semántico que ya contiene nuestras relaciones, medidas y lógica de negocio. Pero repito: es un escenario concreto de Fabric Apps, no la definición de Fabric Apps.
Microsoft ha conseguido que la palabra App necesite ahora alguna explicación adicional. Las tradicionales Power BI Apps y las nuevas Org Apps están orientadas fundamentalmente a empaquetar y distribuir contenido a usuarios de una organización. Una Fabric App es otra cosa. Estamos hablando de una aplicación web desarrollada con código, con su frontend y con servicios de backend que pueden incluir base de datos, API y autenticación.
Por tanto:
Org App → distribuye contenido de Fabric.
Fabric App → permite desarrollar una aplicación sobre Fabric.
Aunque compartan apellido, el objetivo es completamente diferente.
Desde mi punto de vista (que esto quede claro) creo que lo interesante de Fabric Apps no es simplemente que podamos crear una página web desde Fabric. Eso sería quedarse bastante en la superficie. Lo interesante es que Fabric empieza a cubrir otra parte del recorrido.
Hasta ahora habíamos hablado muchísimo de llevar los datos hasta el usuario:
Origen à ETL à Modelo à Análisis
Fabric Apps añade otra posibilidad al final de ese camino:
Datos à Lógica à Aplicación à Acción
Ya no solamente podemos construir una solución para que un usuario vea los datos. Podemos empezar a construir experiencias en las que el usuario trabaje con ellos. Una herramienta interna, una aplicación operacional, una solución que combine datos analíticos y funcionalidad específica, una interfaz completamente personalizada sobre un modelo semántico o simplemente un prototipo que necesitemos validar rápidamente.
Microsoft identifica precisamente escenarios como el prototipado rápido, las herramientas internas, la exploración de datos y las aplicaciones basadas en agentes como algunos de los casos de uso de Fabric Apps.
A día de hoy, Fabric Apps continúa en versión preliminar. Y esto no es solamente una etiqueta. Microsoft establece de forma general que las características de Fabric en preview pueden tener funcionalidad limitada, estar disponibles únicamente en determinadas regiones, cambiar antes de su disponibilidad general y no están pensadas para cargas de producción.
Por tanto, estamos ante una tecnología muy interesante para conocer, probar y empezar a entender. Pero también ante una tecnología que todavía está evolucionando. Y creo que esa es precisamente la posición desde la que tiene sentido acercarse ahora mismo a Fabric Apps.
No preguntarnos todavía si va a sustituir a Power BI, Power Apps o cualquier otra herramienta. La pregunta quizá sea mucho más sencilla:
¿qué ocurre cuando Fabric deja de ser solamente la plataforma donde preparo y analizo mis datos y pasa también a ser la plataforma sobre la que puedo construir una aplicación para trabajar con ellos?
Ahí es donde, al menos para mí, empieza realmente la conversación sobre Fabric Apps.
