Modelos de hospedaje Blazor en ASP.NET Core

En este artículo se explican los modelos de hospedaje de Blazor, centrados principalmente en las aplicaciones Blazor Server y Blazor WebAssembly para versiones de .NET anteriores a .NET 8. Las instrucciones de este artículo son relevantes en todas las versiones de .NET para las aplicaciones de Blazor Hybrid que se ejecutan en plataformas móviles y de escritorio nativas. Las aplicaciones web de Blazor en .NET 8 o posterior se entienden mejor como la forma en que los componentes de Razor se representan, lo que se describe como su modo de representación. Los modos de representación se abordan brevemente en el artículo de información general sobre Aspectos básicos y se tratan en detalle en los modos de representación de ASP.NET Core Blazor del nodo Componentes.

Blazor es un marco web para compilar componentes de UI web (componentes Razor) que se pueden hospedar de maneras diferentes. Los componentes de Razor pueden ejecutarse en el lado servidor en ASP.NET Core (Blazor Server) frente al lado cliente en el explorador en un entorno de ejecución .NET basado en WebAssembly (Blazor WebAssembly, Blazor WASM). También puede hospedar componentes de Razor en aplicaciones nativas móviles y de escritorio que se representan en un control Web View insertado (Blazor Hybrid). Independientemente del modelo de hospedaje, la forma en que se compilan los componentes de Razores la misma. Los mismos componentes de Razor se pueden usar con cualquiera de los modelos de hospedaje sin cambios.

Blazor Server

Con el modelo de hospedaje de Blazor Server, los componentes se ejecutan en el servidor desde una aplicación ASP.NET Core. Las actualizaciones de la interfaz de usuario, el control de eventos y las llamadas de JavaScript se controlan mediante una conexión SignalR usando el protocolo WebSockets. El estado en el servidor asociado a cada cliente conectado se denomina circuito. Los circuitos no están vinculados a una conexión de red específica y pueden tolerar interrupciones temporales de red e intentos por parte del cliente de volver a conectarse al servidor cuando se pierde la conexión.

En una aplicación tradicional representada por el servidor, la apertura de la misma aplicación en varias pantallas del explorador (pestañas o iframes) normalmente no se traduce en demandas adicionales de recursos en el servidor. En el modelo de hospedaje de Blazor Server, cada pantalla del explorador requiere un circuito e instancias independientes del estado del componente que administra el servidor. Blazor considera el cierre de una pestaña del explorador o la navegación a una dirección URL externa una terminación correcta. En el caso de una terminación correcta, el circuito y los recursos asociados se liberan inmediatamente. Un cliente también puede desconectarse de manera no correcta, por ejemplo, debido a una interrupción en la red. Blazor Server almacena los circuitos desconectados durante un intervalo configurable para permitir que el cliente vuelva a conectarse.

En el cliente, el script Blazor establece la conexión SignalR con el servidor. El script se sirve desde un recurso incrustado en el marco de trabajo compartido de ASP.NET Core.

El modelo de hospedaje de Blazor Server ofrece varias ventajas:

• El tamaño de la descarga es significativamente menor que cuando se usa el modelo de hospedaje de Blazor WebAssembly y la aplicación se carga mucho más rápido.
• La aplicación aprovecha al máximo las funciones del servidor, incluido el uso de las API de .NET Core.
• .NET Core en el servidor se usa para ejecutar la aplicación, por lo que las herramientas de .NET existentes, como la depuración, funcionan según lo previsto.
• Se admiten clientes ligeros. Por ejemplo, Blazor Server funciona con los exploradores que no admiten WebAssembly y en los dispositivos con restricción de recursos.
• La base del código de la aplicación .NET/C#, incluido el código de componente de la aplicación, no se sirve a los clientes.

El modelo de hospedaje de Blazor Server tiene las limitaciones siguientes:

• Normalmente existe una mayor latencia. Cada interacción del usuario implica un salto de red.
• No hay soporte técnico sin conexión. Si ocurre un error en la conexión de cliente, se produce un error en la interactividad.
• El escalado de aplicaciones con muchos usuarios requiere recursos de servidor para controlar varias conexiones de cliente y el estado del cliente.
• Se necesita un servidor ASP.NET Core para atender la aplicación. Los escenarios de implementación sin servidor no son posibles, como dar servicio a la aplicación desde una instancia de Content Delivery Network (CDN).

Se recomienda usar Azure SignalR Service para las aplicaciones que adoptan el modelo de hospedaje de Blazor Server. El servicio permite el escalado vertical de una aplicación Blazor Server a un gran número de conexiones SignalR simultáneas.

Blazor WebAssembly

El modelo de hospedaje de Blazor WebAssembly ejecuta componentes del lado cliente en el explorador en un entorno de ejecución de .NET basado en WebAssembly. Los componentes de Razor, sus dependencias y el entorno de ejecución de .NET se descargan en el explorador. Los componentes se ejecutan directamente en el subproceso de interfaz de usuario del explorador. Las actualizaciones de la interfaz de usuario y el control de eventos se producen en el mismo proceso. Los recursos se implementan como archivos estáticos en un servidor o servicio web capaz de servir contenido estático a los clientes.

Las aplicaciones web de Blazor pueden usar el modelo de hospedaje de Blazor WebAssembly para habilitar la interactividad del lado cliente. Cuando se crea una aplicación que se ejecuta exclusivamente bajo el modelo de hospedaje Blazor WebAssembly sin representación e interactividad del lado servidor, la aplicación se denomina "aplicación de Blazor WebAssemblyindependiente".

Cuando una aplicación de Blazor WebAssembly independiente usa una aplicación back-end ASP.NET Core para servir sus archivos, la aplicación se denomina "aplicación de Blazor WebAssemblyhospedada". Con Blazor WebAssembly hospedado, se obtiene una experiencia de desarrollo web de pila completa con .NET, incluida la capacidad de compartir código entre las aplicaciones cliente y servidor, la compatibilidad con la representación previa y la integración con MVC y Razor Pages. Una aplicación cliente hospedada puede interactuar con su aplicación de servidor back-end a través de la red mediante una variedad de marcos de mensajería y protocolos, como API web, gRPC-web y SignalR (Uso de ASP.NET Core SignalR con Blazor).

Una aplicación Blazor WebAssembly creada como aplicación web progresiva (PWA) usa las API de exploradores modernos para habilitar muchas de las funcionalidades de una aplicación cliente nativa, como trabajar sin conexión, ejecutarse en su propia ventana de aplicación, iniciarse desde el sistema operativo del host, recibir notificaciones push y actualizarse automáticamente en segundo plano.

El script de Blazor controla:

• La descarga del entorno de ejecución de .NET, los componentes de Razor y las dependencias de los componentes.
• La inicialización del tiempo de ejecución.

El tamaño de la aplicación publicada, su tamaño de carga, es un factor de rendimiento crítico para la facilidad de uso de una aplicación. Una aplicación grande tarda un tiempo relativamente largo en descargarse en un explorador, lo que repercute en la experiencia del usuario. Blazor WebAssembly optimiza el tamaño de carga para reducir los tiempos de descarga:

• Se ha quitado el código sin usar de la aplicación cuando se publica mediante el recortador del lenguaje intermedio (IL).
• Las respuestas HTTP se comprimen.
• El entorno de ejecución .NET y los ensamblados se almacenan en caché en el explorador.

El modelo de hospedaje de Blazor WebAssembly ofrece varias ventajas:

• En cuanto a las aplicaciones de Blazor WebAssembly, no hay ninguna dependencia del lado servidor de .NET después de descargar la aplicación desde el servidor, por lo que la aplicación sigue funcionando si el servidor se queda sin conexión.
• Los recursos y capacidades del cliente se aprovechan completamente.
• El trabajo se descarga del servidor al cliente.
• En cuanto a las aplicaciones de Blazor WebAssembly independientes, no es necesario un servidor web ASP.NET Core para hospedar la aplicación. Los escenarios de implementación sin servidor son posibles, como dar servicio a la aplicación desde una instancia de Content Delivery Network (CDN).

El modelo de hospedaje de Blazor WebAssembly tiene las limitaciones siguientes:

• Los componentes de Razor están restringidos a las funcionalidades del explorador.
• Se necesita hardware y software del cliente compatible (por ejemplo, compatibilidad con WebAssembly).
• El tamaño de descarga es mayor y los componentes tardan más tiempo en cargarse.
• El código se envía al cliente y no se puede proteger de la inspección y manipulación por parte de los usuarios.

El intérprete de lenguaje intermedio de .NET incluye compatibilidad parcial con el entorno de ejecución Just-In-Time (JIT) para lograr un mejor rendimiento en tiempo de ejecución. El intérprete JIT optimiza la ejecución de códigos de bytes del intérprete reemplazándolos por blobs pequeños de código WebAssembly. El intérprete JIT se habilita automáticamente para las aplicaciones Blazor WebAssembly, excepto cuando se depura.

Blazor admite la compilación Ahead Of Time(AOT), donde puede compilar el código de .NET directamente en WebAssembly. La compilación AOT da como resultado mejoras de rendimiento en tiempo de ejecución a costa de un tamaño de aplicación mayor. Para obtener más información, consulte Herramientas de creación de ASP.NET Core Blazor WebAssembly y compilación anticipada (AOT).

Las mismas herramientas de compilación de WebAssembly de .NET usadas para la compilación de AOT también revinculan el entorno de ejecución de WebAssembly de .NET para recortar el código del entorno de ejecución sin usar. Blazor también recorta el código sin usar de las bibliotecas de .NET Framework. El compilador de .NET precomprime aún más una aplicación Blazor WebAssembly independiente para que la carga útil de la aplicación sea más pequeña.

Los componentes de Razor representados por WebAssembly pueden usar dependencias nativas compiladas para ejecutarse en WebAssembly.

Blazor Hybrid

Blazor también se puede usar para compilar aplicaciones cliente nativas mediante un enfoque híbrido. Las aplicaciones híbridas son aplicaciones nativas que aprovechan las tecnologías web para su funcionalidad. En una aplicación de Blazor Hybrid, los componentes de Razor se ejecutan directamente en la aplicación nativa (no en WebAssembly) junto con cualquier otro código de .NET y representan la interfaz de usuario web basada en HTML y CSS en un control Web View insertado mediante un canal de interoperabilidad local.

Las aplicaciones Blazor Hybrid se pueden crear con diferentes marcos de aplicaciones nativas de .NET, incluidos .NET MAUI, WPF y Windows Forms. Blazor proporciona controles BlazorWebView para agregar componentes de Razor a aplicaciones creadas con estos marcos. El uso de Blazor con .NET MAUI ofrece una manera cómoda de crear aplicaciones multiplataforma Blazor Hybrid para dispositivos móviles y de escritorio, mientras que la integración de Blazor con WPF y Windows Forms puede ser una excelente manera de modernizar las aplicaciones existentes.

Dado que las aplicaciones Blazor Hybrid son aplicaciones nativas, pueden admitir funcionalidades que no están disponibles solo con la plataforma web. Las aplicaciones Blazor Hybrid tienen acceso total a las funcionalidades de la plataforma nativa a través de las API normales de .NET. Las aplicaciones Blazor Hybrid también pueden compartir y reutilizar componentes con aplicaciones Blazor Server o Blazor WebAssembly existentes. Las aplicaciones Blazor Hybrid combinan las ventajas de la Web, las aplicaciones nativas y la plataforma .NET.

El modelo de hospedaje de Blazor Hybrid ofrece varias ventajas:

• Reutilice los componentes existentes que se pueden compartir entre dispositivos móviles, de escritorio y web.
• Aproveche las aptitudes, la experiencia y los recursos de desarrollo web.
• Las aplicaciones tienen acceso total a las funcionalidades nativas del dispositivo.

El modelo de hospedaje de Blazor Hybrid tiene las limitaciones siguientes:

• Las aplicaciones cliente nativas independientes se deben crear, implementar y mantener para cada plataforma de destino.
• Las aplicaciones cliente nativas suelen tardar más tiempo en buscar, descargar e instalar una aplicación web que acceder a ella en un explorador.

Para más información, consulte ASP.NET CoreBlazor Hybrid.

Para obtener más información sobre los marcos de cliente nativos de Microsoft, vea los siguientes recursos:

• .NET Multi-platform App UI (.NET MAUI)
• Windows Presentation Foundation (WPF)
• Windows Forms

¿Qué modelo de hospedaje Blazor debo elegir?

El modelo de hospedaje de un componente se establece mediante su modo de representación, ya sea en tiempo de compilación o en tiempo de ejecución, que se describe con ejemplos en los modos de representación de Blazor de ASP.NET Core. En la tabla siguiente se muestran las consideraciones principales para establecer el modo de representación para determinar el modelo de hospedaje de un componente. En el caso de las aplicaciones de Blazor WebAssembly independientes, todos los componentes de la aplicación se representan en el cliente con el modelo de hospedaje de Blazor WebAssembly.

Entre las aplicaciones Blazor Hybrid se incluyen las aplicaciones de marco .NET MAUI, WPF y Windows Forms.

Característica	Blazor Server	Blazor WebAssembly (WASM)	Blazor Hybrid
Compatibilidad completa con la API de .NET	✔️Se admite	❌No compatible	✔️Se admite
Acceso directo a recursos de red y servidor	✔️Se admite	❌No se admite†	❌No se admite†
Tamaño de carga pequeño con un tiempo de carga inicial rápido	✔️Se admite	❌No compatible	❌No compatible
Velocidad de ejecución casi nativa	✔️Se admite	✔️Se admite‡	✔️Se admite
Código de aplicación seguro y privado en el servidor	✔️Se admite	❌No se admite†	❌No se admite†
Ejecución de aplicaciones sin conexión una vez descargadas	❌No compatible	✔️Se admite	✔️Se admite
Hospedaje de sitios estáticos	❌No compatible	✔️Se admite	❌No compatible
Descarga el procesamiento a los clientes	❌No compatible	✔️Se admite	✔️Se admite
Acceso total a las funcionalidades de cliente nativo	❌No compatible	❌No compatible	✔️Se admite
Implementación basada en web	✔️Se admite	✔️Se admite	❌No compatible

Las aplicaciones †Blazor WebAssembly y Blazor Hybrid pueden usar API basadas en servidor para acceder a recursos de servidor o red, y a código de aplicación privado y seguro.
‡Blazor WebAssembly solo alcanza un rendimiento casi nativo con la compilación Ahead Of Time (AOT).

Después de elegir el modelo de hospedaje de la aplicación, puede generar una aplicación Blazor Server o Blazor WebAssembly a partir de una plantilla de proyecto de Blazor. Para más información, vea Herramientas para ASP.NET Core Blazor.

Para crear una aplicación Blazor Hybrid, vea los artículos existentes en Tutoriales de ASP.NET Core Blazor Hybrid.

Compatibilidad completa con la API de .NET

Los componentes representados para el modelo de hospedaje de Blazor Servery las aplicaciones de Blazor Hybrid tienen compatibilidad completa con la API de .NET, mientras que los componentes representados para Blazor WebAssembly se limitan a un subconjunto de API de .NET. Cuando la especificación de una aplicación requiere una o varias API de .NET que no están disponibles para los componentes representados por WebAssembly, decida representar componentes para Blazor Server o use Blazor Hybrid.

Acceso directo a recursos de red y servidor

Los componentes representados para el modelo de hospedaje de Blazor Server tienen acceso directo al servidor y a los recursos de red en los que se ejecuta la aplicación. Dado que los componentes hospedados mediante Blazor WebAssembly o Blazor Hybrid se ejecutan en un cliente, no tienen acceso directo a los recursos de servidor y de red. Los componentes pueden acceder indirectamente a los recursos de servidor y red mediante API basadas en servidor protegidas. Es posible que las API basadas en servidor estén disponibles mediante bibliotecas, paquetes y servicios de terceros. Tenga en cuenta las consideraciones siguientes:

• Las bibliotecas, los paquetes y los servicios de terceros pueden ser costosos de implementar y mantener, tener un soporte técnico débil o presentar riesgos de seguridad.
• Si la organización desarrolla de forma interna una o varias API basadas en servidor, se necesitan recursos adicionales para compilarlas y mantenerlas.

Use el modelo de hospedaje de Blazor Server para evitar la necesidad de exponer las API del entorno de servidor.

Tamaño de carga pequeño con un tiempo de carga inicial rápido

La representación de componentes del servidor reduce el tamaño de la carga útil de la aplicación y mejora los tiempos de carga iniciales. Cuando se desee un tiempo de carga inicial rápido, use el modelo de hospedaje Blazor Server o considere la posibilidad de representar el lado servidor estático.

Velocidad de ejecución casi nativa

Las aplicaciones Blazor Hybrid se ejecutan mediante el entorno de ejecución de .NET de forma nativa en la plataforma de destino, que ofrece la mejor velocidad posible.

Los componentes representados para el modelo de hospedaje de Blazor WebAssembly, incluidas las aplicaciones web progresivas (PWA), y las aplicaciones de Blazor WebAssembly independientes se ejecutan mediante el entorno de ejecución de .NET para WebAssembly, que es más lento que ejecutarse directamente en la plataforma. Considere la posibilidad de usar el modelo de compilación anticipado para mejorar el rendimiento en tiempo de ejecución al usar Blazor WebAssembly.

Código de aplicación seguro y privado en el servidor

Mantener el código de aplicación de forma segura y privada en el servidor es una característica integrada de los componentes representados para el modelo de hospedaje de Blazor Server. Los componentes representados mediante los modelos de hospedaje Blazor WebAssembly o Blazor Hybrid pueden usar API basadas en servidor para acceder a la funcionalidad que se debe mantener privada y segura. Se aplican las consideraciones para desarrollar y mantener API basadas en servidor que se describen en la sección Acceso directo a recursos de servidor y red. Si el desarrollo y el mantenimiento de las API basadas en servidor no son deseables para mantener el código de aplicación seguro y privado, adopte el modelo de hospedaje de Blazor Server.

Ejecución de aplicaciones sin conexión una vez descargadas

Las aplicaciones de Blazor WebAssembly compiladas como aplicaciones web progresivas (PWA) y las aplicaciones de Blazor Hybrid se pueden ejecutar sin conexión, lo que resulta especialmente útil cuando los clientes no se pueden conectar a Internet. Los componentes representados para el modelo de hospedaje de Blazor Serverno se pueden ejecutar cuando se pierde la conexión al servidor. Si una aplicación se tiene que ejecutar sin conexión, las mejores opciones son instancias de Blazor WebAssembly y Blazor Hybrid independientes.

Hospedaje de sitios estáticos

El hospedaje de sitios estáticos es posible con las aplicaciones de Blazor WebAssembly porque se descargan en los clientes como un conjunto de archivos estáticos. Las aplicaciones independientes de Blazor WebAssembly no requieren un servidor para ejecutar código del lado servidor para descargar y ejecutar, y se pueden entregar a través de una red de entrega de contenido (CDN) (por ejemplo, Azure CDN).

Aunque las aplicaciones Blazor Hybrid se compilan en uno o varios recursos de implementación independientes, los recursos normalmente se proporcionan a los clientes mediante una tienda de aplicaciones de terceros. Si el hospedaje estático es un requisito de la aplicación, seleccione Blazor WebAssembly.

Descarga el procesamiento a los clientes

Las aplicaciones Blazor WebAssembly y Blazor Hybrid se ejecutan en clientes y, por tanto, descargan el procesamiento en ellos. Las aplicaciones Blazor Server se ejecutan en un servidor, por lo que la demanda de recursos de servidor suele aumentar con el número de usuarios y la cantidad de procesamiento necesaria por usuario. Cuando es posible descargar la mayoría o todo el procesamiento de una aplicación a los clientes y la aplicación procesa una cantidad significativa de datos, la mejor opción es Blazor WebAssembly o Blazor Hybrid.

Acceso total a las funcionalidades de cliente nativo

Las aplicaciones Blazor Hybrid tienen acceso total a las funcionalidades de API de cliente nativo mediante marcos de aplicaciones nativas de .NET. En las aplicaciones Blazor Hybrid, los componentes Razor se ejecutan directamente en la aplicación nativa, no en WebAssembly. Cuando las funcionalidades de cliente completas son un requisito, la mejor opción es Blazor Hybrid.

Implementación basada en web

Las aplicaciones web de Blazor se actualizan en la siguiente actualización de la aplicación desde el explorador.

Las aplicaciones Blazor Hybrid son aplicaciones cliente nativas que normalmente requieren un instalador y un mecanismo de implementación específico de la plataforma.

Establecimiento del modelo de hospedaje de un componente

Para establecer el modelo de hospedaje de un componente en Blazor Server o Blazor WebAssembly en tiempo de compilación o dinámicamente en tiempo de ejecución, establezca su modo de representación. Los modos de representación se explican completamente y se muestran en el artículo de modos de representación de Blazor de ASP.NET Core. No se recomienda saltarse este artículo para ir directamente al artículo Modos de representación sin leer el contenido de los artículos entre esos dos artículos. Por ejemplo, los modos de representación se entienden más fácilmente examinando los ejemplos de componentes de Razor, pero el funcionamiento y la estructura básica de componentes de Razor no se tratan hasta que se lee el artículo de aspectos básicos de Blazor de ASP.NET Core. También es útil obtener información sobre las herramientas y las plantillas de proyecto de Blazor antes de trabajar con los ejemplos de componentes del artículo Modos de representación.