Antes de hablar de qué son las Code Apps, hay que hablar de por qué existen. Y para eso necesitamos ser honestos sobre las limitaciones que llevaban años frustrando a los desarrolladores que trabajaban con Power Platform.
Objetivos de aprendizaje
- Comprender qué problemas concretos llevaron a Microsoft a crear las Code Apps
- Identificar las limitaciones reales de Canvas Apps y Model-Driven Apps para equipos de desarrollo profesionales
- Entender el hueco que existía entre las herramientas low-code y el desarrollo web tradicional
El dilema del desarrollador en Power Platform
Imagina esta situación: eres desarrollador en una empresa que usa Dynamics 365 y Power Platform. Te piden construir una aplicación de gestión de incidencias que debe tener una interfaz muy personalizada, con filtros avanzados, gráficas en tiempo real y una experiencia de usuario que nada tenga que envidiar a una SPA (Single Page Application) moderna.
Abres Power Apps Studio y te encuentras con Canvas Apps. Puedes hacer cosas, sí. Pero rápidamente empiezas a toparte con paredes: la lógica de las fórmulas de Power Fx se vuelve inmanejable cuando la aplicación crece, el rendimiento empieza a degradarse cuando tienes demasiados controles en pantalla, y cualquier cosa que se salga del modelo estándar de controles te obliga a crear un componente PCF, que tiene su propia curva de aprendizaje y limitaciones.
Las Model-Driven Apps, por otro lado, son estupendas para la gestión de datos empresariales, pero están diseñadas para un patrón muy concreto de formularios y vistas. Si necesitas una interfaz radicalmente diferente, simplemente no es la herramienta adecuada.
Las frustraciones que acumulaban los equipos técnicos
He trabajado con organizaciones donde el equipo de desarrollo tenía que tomar una decisión difícil ante cada proyecto. O usaban Power Platform y aceptaban sus limitaciones, o salían completamente de ella y construían una aplicación web tradicional con React, Angular o Vue, perdiendo entonces todos los beneficios de la plataforma: la autenticación integrada con Entra ID, las políticas de DLP, el acceso a los 1.500+ conectores de Power Platform, la gestión del ciclo de vida a través de soluciones, etc.
Ese espacio intermedio no existía. O eras low-code o eras full-code fuera de la plataforma. No había una opción que combinase lo mejor de los dos mundos: la potencia y flexibilidad del código con la gobernanza y los servicios de Power Platform.
El problema específico de PCF
Alguien podría argumentar: "¿Y los componentes PCF? ¿No sirven para eso?" La respuesta corta es: no del todo. PCF (Power Apps Component Framework) permite crear componentes de interfaz personalizados que se embeben en Canvas Apps o Model-Driven Apps. Son útiles, pero tienen una limitación fundamental: son componentes, no aplicaciones completas.
Un PCF te permite crear un control de mapa personalizado, un selector de fechas con lógica especial, o una visualización de datos única. Pero no puedes construir una aplicación entera con routing propio, gestión de estado global, múltiples páginas con navegación... sin montar una arquitectura tremendamente compleja que va en contra del espíritu de la herramienta.
Además, los PCF tienen restricciones importantes en cuanto a lo que pueden hacer en el contexto del navegador, y para muchos casos de uso de aplicaciones completas simplemente no escalan bien.
Lo que los desarrolladores necesitaban
La demanda del mercado era clara: los equipos de desarrollo profesionales necesitaban poder usar sus habilidades y herramientas modernas (React, TypeScript, VS Code, npm) para construir aplicaciones completas, pero sin tener que abandonar el ecosistema de Power Platform.
Necesitaban poder usar la autenticación de Entra ID sin tener que implementarla desde cero. Necesitaban acceso a Dataverse con tipos seguros, sin escribir llamadas REST manuales. Necesitaban que sus aplicaciones quedaran sujetas a las políticas de DLP de la organización. Y necesitaban poder desplegar y gestionar el ciclo de vida a través del mismo sistema de soluciones que el resto de componentes de Power Platform.
En definitiva, necesitaban ser desarrolladores profesionales y al mismo tiempo permanecer dentro del ecosistema de Power Platform. Ahí es exactamente donde encajan las Code Apps.
Puntos clave
- Canvas Apps y Model-Driven Apps tienen limitaciones reales que frustran a desarrolladores con habilidades avanzadas
- PCF resuelve el problema de componentes, pero no de aplicaciones completas
- Antes de Code Apps, la alternativa era salir de Power Platform y perder todos sus beneficios
- Las Code Apps nacen para cerrar esa brecha: código moderno + gobernanza de Power Platform