Interactividad Blazor

Blazor te permite lanzar un portal en uno de tres modos de interactividad: Servidor, WebAssembly o Auto. El modo elige cómo se ejecutan los componentes interactivos (a través de una conexión SignalR en el servidor, tal como compilado .NET en el navegador, o ambos) y decide qué se genera en el diseño de tu proyecto. Power Portals Pro funciona correctamente en los tres; Las diferencias están en la forma de despliegue y el cableado del proyecto, no en las características del marco.

Los Tres Modos

Servidor

Los componentes interactivos se ejecutan en el servidor. Cada usuario conectado mantiene una conexión SignalR abierta de vuelta al anfitrión, y cada evento de la interfaz hace viajes de ida y vuelta al servidor.

• La descarga más pequeña del cliente. El navegador recibe HTML simple y un pequeño cargador SignalR — no se envía ningún tiempo de ejecución .NET al cliente.
• Capacidades completas del servidor. Los componentes inyectan cualquier servicio del lado servidor directamente (cliente Dataverse, configuración, sistema de archivos) sin pasar por HTTP.
• El despliegue más sencillo. Uno ASP.NET host Core, no hay un paquete separado de WebAssembly que publicar.

Compensaciones:

• Anfitrión con estado. El circuito de cada usuario está fijado a una única instancia de servidor; El escalado horizontal necesita sesiones fijas, y un reinicio del anfitrión se corta en cada sesión activa.
• La latencia de la interfaz sigue a la latencia de red. Cada clic, pulsación de tecla y desplazamiento va de ida y vuelta al servidor, así que los usuarios con enlaces de alta latencia sienten la app lenta.

WebAssembly

Los componentes interactivos se ejecutan en el navegador como código compilado .NET. La función del servidor se reduce a servir archivos estáticos y los endpoints HTTP API del framework bajo /api/auth/* y /api/*.

• Servidor sin estado. El host escala horizontalmente sin sesiones fijas, los reinicios no causan interrupciones visibles y el coste de memoria por usuario en el servidor es casi nulo.
• Interfaz muy rápida. La mayoría de la interacción se mantiene dentro del navegador — no hay SignalR de ida y vuelta por clic — por lo que la aplicación se siente instantánea una vez cargado el paquete.
• Con capacidad de conexión sin conexión. Un portal cargado sigue renderizando y validando contra datos almacenados en caché incluso cuando la red se cae, sincronizándose de nuevo con la API cuando esta regresa.

Compensaciones:

• Descarga inicial. El runtime de .NET, los ensamblajes del framework y el código de tu portal se envían al navegador en la primera carga (comprimidos, a menudo un par de MB). Las visitas posteriores se cargan desde la caché del navegador.
• Se requiere superficie de API. Todo lo que la interfaz necesita del servidor debe exponerse como un punto final HTTP. Power Portals Pro proporciona los endpoints de datos y autenticación desde el primer momento; La lógica de servidor personalizada necesita sus propios controladores o endpoints de API mínima.
• Rendimiento en navegador. El trabajo con mucha CPU (grandes cuadrículas, cálculos complejos de gráficos) se ejecuta a velocidad WebAssembly, que es rápida pero más lenta que el .NET nativo del lado del servidor.

Auto

La primera pintura proviene del servidor (para que el usuario vea el contenido inmediatamente) y el tiempo de ejecución cambia de forma transparente a WebAssembly una vez que el paquete cliente termina de descargarse. Auto = Primero el servidor, WebAssembly después, en las mismas rutas.

• Mejor carga percibida + mejor experiencia de usuario en estado estable. Los usuarios obtienen un first paint instantáneo sin esperar el paquete WASM, y luego disfrutan de las interacciones ágiles de WebAssembly una vez que el runtime está almacenado en caché en su navegador.
• Despliegue único. Un host, un paso de publicación — igual que en WebAssembly, con el tiempo de ejecución del servidor llevado durante el prerender.

Compensaciones:

• El diseño de proyectos más complejo. Ambos tiempos de ejecución deben estar cableados; Los componentes deben funcionar correctamente bajo cualquiera de los dos motores de renderizador (no se inyectan servicios exclusivos de servidor en componentes compartidos).
• Breve ventana renderizada por el servidor. En la primera visita, la página se renderiza en el lado del servidor hasta que se completa el cambio WASM — la plantilla de Power Portals Pro oculta esta transición con una superposición de carga para que los usuarios no vean el estado intermedio.

Propina

Este sitio de documentación funciona en modo Automático. Abre la pestaña de red de las herramientas de desarrollo del navegador en la primera carga y verás que el HTML renderizado por el servidor llega primero, luego el flujo del paquete WASM en uno o dos segundos — tras lo cual las navegaciones dejan de llegar al servidor para HTML.

Cuál elegir

Reglas generales cuando no hay una restricción específica que obligue a elegir:

• Elige Server si el portal tiene pocos usuarios concurrentes, funciona dentro de una red corporativa con conexiones estables, o si tu equipo es nuevo en Blazor y quiere el modelo mental más sencillo.
• Elige WebAssembly si el portal es orientado al cliente con alta concurrencia, si tu factura de alojamiento escala con sesiones activas o si necesitas comportamiento offline. Acepta el coste inicial de descarga como una visita única por visitante.
• Elige Auto si quieres el WebAssembly en estado estable sin pagar la latencia de primer pintado para descargar el pack. La mayoría de los portales de producción acaban aquí.

Chuletas

¿Qué cambia entre los tres modos, archivo por archivo? Usa esto como referencia al comparar un proyecto generado con una de las plantillas, o al buscar una discrepancia tras un cambio manual.

Diseño del proyecto

Los tres modos generan un proyecto host de servidor Y un proyecto hermano .Client . Lo que difiere es el .ClientSDK de 's y si realmente está compilado a un paquete WebAssembly.

• Server — .Client usa Microsoft.NET.Sdk.Razor; es una biblioteca de clases que contiene componentes compartidos pero no se publica como WASM.
• WebAssembly — .Client se usa Microsoft.NET.Sdk.BlazorWebAssembly con su propio Program.cs, compilado en un paquete descargable.
• Auto — igual que WebAssembly: Microsoft.NET.Sdk.BlazorWebAssembly con su propio Program.cs.

.csproj Diferencias

El .Client SDK del proyecto cambia, y los paquetes de framework específicos de WebAssembly solo aparecen cuando el host realmente ejecuta WASM:

Referencias adicionales de paquetes cuando WebAssembly o Auto están activos:

Server Program.cs — Registro de servicios

AddRazorComponents() recoge los pares de componentes apropiados en el modo de renderizado según los métodos de construcción encadenados:

Server Program.cs — Mapeo de puntos finales

MapRazorComponents<App>() encadena los extremos de modo de renderizado correspondientes:

App.razor — Política de renderizado por ruta

El PageRenderMode getter en App.razor decide qué renderizador utiliza cada ruta. Los anfitriones de servidor devuelven el servidor en todas partes; Los hosts de WebAssembly y Auto tienen que fijar explícitamente las /Account/* rutas para que la resolución solo IAuthService de WASM:

Por qué está fijado /Account/*

El primer paint de Auto se ejecuta bajo el renderizador del servidor, pero las páginas IAuthService de cuenta solo están registradas en el grafo DI del cliente WASM. Sin el pin explícito a InteractiveWebAssemblyRenderMode(prerender: false), un host automático no resuelve [Inject] IAuthService en el prerenderizado de sesión en frío. prerender: false se salta completamente el paso de prerenderizado en el lado del servidor, por lo que la página solo se renderiza una vez, en el entorno de ejecución WASM.

. Cliente/Program.cs — Solo cuando es interactivo

Los hosts solo de servidor no tienen .Client/Program.cs una (es .Client una biblioteca de clase Razor). Los hosts WebAssembly y Auto incluyen este archivo, que configura el entorno de ejecución WASM, registra el HttpClient reenvío de credenciales de cookies, registra los servicios cliente WASM de Power Portals Pro y pre-busca la localización transversal al inicio:

Páginas de identidad / cuenta

Power Portals Pro incluye dos conjuntos paralelos de páginas de cuenta — una para cada contexto de renderizado. El conjunto que está en tu proyecto depende del modo del anfitrión:

• Server — páginas de Razor renderizadas por servidor bajo Components/Account/Pages/ uso UserManager directo. Endpoints de post-formulario registrados a través app.MapAdditionalIdentityEndpoints()de .
• WebAssembly / Auto — páginas interactivas bajo .Client/Pages/Account/ el uso del wrapper del IAuthService framework. Los endpoints JSON registrados mediante app.MapAuthEndpoints<PortalUser>() manejo de inicio de sesión, registro, gestión/* y finalización externa de inicio de sesión como application/json llamadas.

Próximos pasos

Si ya tienes un proyecto en un modo y quieres convertir a otro, consulta la página de Interactividad de Switch Blazor para los cambios archivo por archivo.