Puntos clave
- Prefiere pantallas enfocadas y un modelo de navegación a una megapantalla que se adueña de todo el proceso.
- Diseña primero para la delegación; trata los subrayados azules como deuda de arquitectura, no como ruido del editor.
- Elimina las búsquedas N+1 en galerías; precarga con vistas de Dataverse ya preparadas y argumenta con trazas de Monitor.
- Pon la lógica de elegibilidad, la agregación y la consistencia en Dataverse; deja Power Fx para la interacción.
- Presupuesta las aperturas simultáneas (muchos usuarios en el mismo momento), no solo el arranque en frío en un portátil.
- Mantén la identidad, los privilegios de Dataverse y el empaquetado de ALM en la misma conversación.
Canvas es estupendo hasta que una pantalla se convierte en un sistema distribuido: galerías anidadas, fan-out en OnStart y reglas de negocio en Power Fx porque era más rápido.
Las propias arquitecturas de referencia de rendimiento de Microsoft marcan una dirección clara. Lleva el trabajo pesado hacia Dataverse y mantén las pantallas enfocadas.
Modelo con nombre: canvas como superficie, Dataverse como motor
- Superficie canvas: pantallas enfocadas, navegación y Power Fx solo para la interacción. Árboles de controles ligeros que se desempaquetan limpiamente en ALM.
- Motor Dataverse: las vistas, las columnas calculadas o de resumen, los plugins y las API personalizadas se encargan de la elegibilidad, la agregación y la consistencia entre tablas.
- Contrato de plataforma: consultas delegables, nada de cargar tablas completas en colecciones en OnStart, nada de búsquedas N+1, presupuestos en Monitor que incluyan aperturas simultáneas, y límites de identidad y de paquete.
- Contrato: a escala de plataforma, canvas es la superficie de interacción. Dataverse hace el trabajo pesado. Las fórmulas anidadas en la app no son un motor de reglas compartido cuando varias apps tienen que coincidir.
Figura 1. Canvas como superficie, Dataverse como motor. Deja Power Fx para la interacción. Pon las reglas compartidas donde viven los datos.
Contexto y restricción
Una canvas app puede ir ágil con una tabla de demo pequeña y desmoronarse cuando la tabla crece y muchos usuarios comparten un Dataverse con mucha carga. Las fórmulas no estaban "mal". El trabajo estaba en el sitio equivocado.
La delegación no es un aviso que haya que silenciar. Es la diferencia entre consultar la tabla y consultar una muestra. Microsoft documenta que, cuando una consulta no se puede delegar, Power Apps procesa un lote local limitado (500 por defecto, hasta 2,000 si subes el límite). Subir el límite no arregla el diseño. Solo aplaza los resultados incompletos hasta que la tabla crece.
Los usuarios simultáneos amplifican los patrones con muchas llamadas. Las búsquedas N+1, las cargas de colecciones en OnStart y las pantallas inactivas que siguen consultando convierten una buena demo en un incidente de plataforma.
La figura 2 es el planteamiento de Microsoft sobre el rendimiento de canvas alineado con la plataforma. La dirección es clara: menos fan-out en la app y más trabajo en el servidor.
Figura 2. Optimizar canvas apps con una arquitectura alineada con la plataforma. Fuente: Microsoft Learn: optimize canvas app performance.
Diseño
1. Divide las megapantallas
Una pantalla que se adueña de todo el proceso de negocio cuesta de cargar, cuesta de desempaquetar con PAC y cuesta de revisar en ALM. Las pantallas separadas se desempaquetan limpiamente, cargan menos árbol de controles sin usar y te dan límites de navegación sobre los que puedes razonar. Prefiere pantallas enfocadas a una única obra maestra con scroll.
2. Diseña primero para la delegación
Escribe filtros y ordenaciones que el origen de datos pueda ejecutar. Con Dataverse, prefiere comparaciones simples, StartsWith y columnas indexadas. Trata los subrayados azules como deuda de arquitectura, no como ruido del editor. Si un requisito no se puede expresar como una consulta delegable, mueve la lógica: vistas de Dataverse, columnas calculadas o de resumen, plugins, o un primer filtro acotado y después un retoque local. No cargues "todas las filas" en una colección al arrancar haciendo como si fuera una base de datos.
3. Elimina el acceso a datos N+1
Las búsquedas por celda y las galerías anidadas que consultan Dataverse cada una generan fan-out con uso simultáneo. Precarga lo que necesita la pantalla, usa vistas que ya den forma al conjunto de filas y filtra en el servidor. Mide con Monitor: argumenta con trazas, no con sensaciones sobre un indicador de carga.
La figura 3 es el contrato de acceso a datos que evita que producción parezca completa hasta la fila 501.
Figura 3. Primero la delegación. Las vistas preparadas y la precarga ganan a las colecciones usadas como warehouse. Subir el límite de filas solo aplaza los resultados incompletos.
4. Pon las reglas donde viven los datos
La elegibilidad compleja, la agregación y la consistencia entre tablas van más cerca de Dataverse que en ForAll anidados en la app. Power Fx es excelente para la interacción. Es un mal motor de reglas compartido cuando varias apps tienen que coincidir. La lógica en el servidor te da una sola definición y menos datos enviados a la app.
5. Presupuesta el comportamiento simultáneo, no solo el arranque en frío
Un fan-out en OnStart que parece correcto para un solo maker se vuelve doloroso cuando muchos usuarios abren la app en la misma franja. Las pantallas inactivas que mantienen vivos temporizadores y consultas desperdician capacidad. Los usuarios simultáneos necesitan menos idas y vueltas por acción y menos trabajo antes de la primera interacción. Los presupuestos de rendimiento deberían incluir "mucha gente ha abierto la pantalla de inicio a la vez", no solo "mi portátil después de recompilar".
La figura 4 explica por qué dividir pantallas y la simultaneidad van en la misma conversación de diseño.
Figura 4. Las pantallas enfocadas se desempaquetan limpiamente y cargan menos árbol sin usar. Presupuesta las aperturas simultáneas de la pantalla de inicio, no solo un arranque en frío en un portátil.
6. Mantén la identidad y ALM en la misma conversación
Incluso las canvas apps forman parte de una historia más amplia de identidad y ALM. Quién puede ejecutar la app, qué privilegios de Dataverse tiene y cómo se mueve el paquete entre entornos no son detalles para después. Una pantalla rápida con el rol de seguridad equivocado sigue estando mal.
La figura 5 es el planteamiento de Learn sobre roles y privilegios. La velocidad sin el modelo de acceso correcto sigue estando mal.
Figura 5. Incluso las canvas apps forman parte de una historia más amplia de identidad y ALM. Fuente: Microsoft Learn: security roles and privileges.
Errores comunes
Una pantalla se adueña del proceso. La superficie YAML se vuelve imposible de revisar. Los diffs de PAC son ruido. El coste de carga crece con cada control que olvidaste que estaba ahí.
Fórmulas no delegables en producción. Los resultados parecen completos hasta la fila 501. Subir el límite de filas a 2,000 solo programa el mismo bug para más adelante.
Colecciones como warehouse. OnStart carga miles de filas "para ir más rápido". Las aperturas simultáneas machacan Dataverse y aun así se pierden filas que el filtro nunca vio.
Reglas de negocio solo en Power Fx. La siguiente app vuelve a implementar la misma elegibilidad. Los números no coinciden. Nadie sabe qué fórmula es la canónica.
Consultas en reposo. Las pantallas dejan conexiones y temporizadores en marcha. Los usuarios simultáneos pagan un trabajo que nadie ha pedido.
Nadie abre Monitor. Los equipos discuten propiedades de Gallery mientras la traza muestra una cascada de búsquedas. Sin Monitor, optimizas la capa equivocada.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Los límites entre pantallas y el modelo de navegación (sin megapantalla por defecto).
- Qué lógica va en Dataverse (vistas, columnas calculadas o de resumen, plugins) y cuál en Power Fx (solo interacción).
- Los patrones de acceso a datos aprobados para producción: consultas delegables, nada de cargar tablas completas en colecciones en OnStart, nada de búsquedas N+1 en galerías.
- Presupuestos de rendimiento verificados con Monitor, incluidos los escenarios de aperturas simultáneas.
- Una política para el límite de filas: subirlo por encima del valor por defecto exige una excepción por escrito y un plan para recuperar la delegación.
- Las expectativas de empaquetado de ALM: límites de pantallas y componentes que se desempaqueten limpiamente con PAC.
Adáptalo antes de usarlo
Llevar el trabajo a Dataverse supone más modelado y a veces más ayuda de desarrolladores profesionales (plugins, vistas cuidadas). Los makers pierden parte de la libertad de "cambiarlo esta tarde en la barra de fórmulas". A cambio ganas corrección con volumen y menos sorpresas con carga simultánea.
Dividir pantallas añade diseño de navegación. Los usuarios hacen más clics. La alternativa es una sola pantalla que nunca termina de cargar en un día con mucha actividad.
Las reglas estrictas de delegación frenan la entrega de funcionalidades cuando un filtro sofisticado en la app podría salir esta noche. Saca ese filtro solo sobre un conjunto pequeño comprobado, o rediseña para que el servidor pueda responder. Los resultados incompletos en producción son peores que una historia retrasada.
La disciplina de ALM (apps más pequeñas, límites más claros) cuesta tiempo de proceso. Los paquetes gigantes de una sola app cuestan tiempo de incidentes.
Referencias principales: Microsoft Learn: optimize canvas app performance, How to create performant Power Apps y Understand delegation in canvas apps.
Así canvas sigue siendo estupendo cuando los datos de la demo crecen.