Modelos de hospedaje Blazor en ASP.NET Core

En este artículo se explican los distintos Blazor modelos de hospedaje y cómo elegir cuál usar.

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, la aplicación se ejecuta 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. El estado en el servidor asociado a cada cliente conectado se denomina circuito. Un circuito puede 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 una aplicación 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.

The browser interacts with the app (hosted inside of an ASP.NET Core app) on the server over a SignalR connection.

En el cliente, el script Blazor (blazor.server.js) establece la conexión SignalR con el servidor. El script se sirve a la aplicación del lado cliente desde un recurso incrustado en el marco compartido de ASP.NET Core. La aplicación del lado cliente es responsable de conservar y restaurar el estado de la aplicación según sea necesario.

El modelo de hospedaje de Blazor Server ofrece varias ventajas:

  • El tamaño de la descarga es bastante menor que una aplicación 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, las aplicaciones Blazor Server funcionan 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 se produce un error en la conexión del cliente, la aplicación deja de funcionar.
  • 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 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

Las aplicaciones Blazor WebAssembly se ejecutan en el lado cliente del explorador en un entorno de ejecución .NET basado en WebAssembly. La aplicación Blazor, sus dependencias y el entorno de ejecución de .NET se descargan en el explorador. La aplicación se ejecuta 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 de la aplicación se implementan como archivos estáticos en un servidor o servicio web capaz de servir contenido estático a los clientes.

Blazor WebAssembly: The Blazor app runs on a UI thread inside the browser.

Cuando la aplicación Blazor WebAssembly se crea para su implementación sin una aplicación de back-end ASP.NET Core, se denomina aplicación Blazor WebAssemblyindependiente. Cuando la aplicación se crea para su implementación con una aplicación de back-end para dar servicio a sus archivos, la aplicación se denomina aplicación 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).

El script blazor.webassembly.js lo proporciona el marco y controla:

  • La descarga del tiempo de ejecución de .NET, la aplicación y las dependencias de la aplicación.
  • La inicialización del tiempo de ejecución para ejecutar la aplicación.

El modelo de hospedaje de Blazor WebAssembly (WASM) ofrece varias ventajas:

  • 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.
  • 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:

  • La aplicación está restringida a las capacidades del explorador.
  • Se necesita hardware y software del cliente compatible (por ejemplo, compatibilidad con WebAssembly).
  • El tamaño de descarga es mayor y las aplicaciones tardan más tiempo en cargarse.

Blazor WebAssembly 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 más información, vea Hospedaje e implementación de ASP.NET Core Blazor WebAssembly.

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 WebAssembly incluye compatibilidad para recortar el código sin usar de las bibliotecas de .NET Core Framework. Para más información, vea Globalización y localización de Blazor de ASP.NET Core. El compilador de .NET precomprime aún más una aplicación Blazor WebAssembly para una carga de aplicación más pequeña.

Las aplicaciones Blazor 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.

Hybrid apps with .NET and Blazor render UI in a Web View control, where the HTML Document Object Model (DOM) interacts with Blazor and .NET of the native desktop or mobile app.

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:

¿Qué modelo de hospedaje Blazor debo elegir?

Seleccione el modelo de hospedaje de Blazor en función de los requisitos de características de la aplicación. En la tabla siguiente se muestran las consideraciones principales para seleccionar el modelo de hospedaje.

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

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.

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

Las aplicaciones Blazor Server y Blazor Hybrid tienen compatibilidad completa con la API de .NET, mientras que las aplicaciones Blazor WebAssembly se limitan a un subconjunto de las API de .NET. Cuando la especificación de una aplicación necesita una o varias API de .NET que no están disponibles para las aplicaciones Blazor WebAssembly, elija Blazor Server o Blazor Hybrid.

Acceso directo a recursos de red y servidor

Las aplicaciones Blazor Server tienen acceso directo a los recursos de servidor y red donde se ejecuta la aplicación. Como las aplicaciones Blazor WebAssembly y Blazor Hybrid se ejecutan en un cliente, no tienen acceso directo a los recursos de servidor y red. Las aplicaciones Blazor WebAssembly y Blazor Hybrid 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.

Para evitar las API basadas en servidor para las aplicaciones Blazor WebAssembly o Blazor Hybrid, adopte Blazor Server, que puede acceder directamente a los recursos de servidor y red.

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

Las aplicaciones Blazor Server tienen tamaños de carga relativamente pequeños con tiempos de carga iniciales más rápidos. Cuando quiera un tiempo de carga inicial rápido, adopte Blazor Server.

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

El mantenimiento del código de la aplicación de forma segura y privada en el servidor es una característica integrada de Blazor Server. Las aplicaciones Blazor WebAssembly y Blazor Hybrid pueden usar API hospedadas en el servidor para acceder a funcionalidades que deben mantenerse privadas y seguras. 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 Blazor WebAssembly y Blazor Hybrid se pueden ejecutar sin conexión, lo que resulta especialmente útil cuando los clientes no se pueden conectar a Internet. Las aplicaciones Blazor Server no 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 Blazor WebAssembly y Blazor Hybrid.

Hospedaje de sitios estáticos

El hospedaje de sitios estáticos es posible con las aplicaciones Blazor WebAssembly porque se descargan en los clientes como un conjunto de archivos estáticos. Las aplicaciones Blazor WebAssembly no necesitan que un servidor ejecute código del lado servidor para descargarse y ejecutarse. Las aplicaciones Blazor WebAssembly se pueden entregar mediante 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.

Recursos adicionales

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). 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, la aplicación se ejecuta 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. El estado en el servidor asociado a cada cliente conectado se denomina circuito. Un circuito puede 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 una aplicación 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.

The browser interacts with the app (hosted inside of an ASP.NET Core app) on the server over a SignalR connection.

En el cliente, el script Blazor (blazor.server.js) establece la conexión SignalR con el servidor. El script se sirve a la aplicación del lado cliente desde un recurso incrustado en el marco compartido de ASP.NET Core. La aplicación del lado cliente es responsable de conservar y restaurar el estado de la aplicación según sea necesario.

El modelo de hospedaje de Blazor Server ofrece varias ventajas:

  • El tamaño de la descarga es bastante menor que una aplicación 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, las aplicaciones Blazor Server funcionan 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 se produce un error en la conexión del cliente, la aplicación deja de funcionar.
  • 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 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

Las aplicaciones Blazor WebAssembly se ejecutan en el lado cliente del explorador en un entorno de ejecución .NET basado en WebAssembly. La aplicación Blazor, sus dependencias y el entorno de ejecución de .NET se descargan en el explorador. La aplicación se ejecuta 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 de la aplicación se implementan como archivos estáticos en un servidor o servicio web capaz de servir contenido estático a los clientes.

Blazor WebAssembly: The Blazor app runs on a UI thread inside the browser.

Cuando la aplicación Blazor WebAssembly se crea para su implementación sin una aplicación de back-end ASP.NET Core, se denomina aplicación Blazor WebAssemblyindependiente. Cuando la aplicación se crea para su implementación con una aplicación de back-end para dar servicio a sus archivos, la aplicación se denomina aplicación 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).

El script blazor.webassembly.js lo proporciona el marco y controla:

  • La descarga del tiempo de ejecución de .NET, la aplicación y las dependencias de la aplicación.
  • La inicialización del tiempo de ejecución para ejecutar la aplicación.

El modelo de hospedaje de Blazor WebAssembly (WASM) ofrece varias ventajas:

  • 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.
  • 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:

  • La aplicación está restringida a las capacidades del explorador.
  • Se necesita hardware y software del cliente compatible (por ejemplo, compatibilidad con WebAssembly).
  • El tamaño de descarga es mayor y las aplicaciones tardan más tiempo en cargarse.

Blazor WebAssembly incluye compatibilidad para recortar el código sin usar de las bibliotecas de .NET Core Framework. Para más información, vea Globalización y localización de Blazor de ASP.NET Core.

¿Qué modelo de hospedaje Blazor debo elegir?

Seleccione el modelo de hospedaje de Blazor en función de los requisitos de características de la aplicación. En la tabla siguiente se muestran las consideraciones principales para seleccionar el modelo de hospedaje.

Característica Blazor Server Blazor WebAssembly (WASM)
Compatibilidad completa con la API de .NET ✔️
Acceso directo a recursos de red y servidor ✔️ ❌†
Tamaño de carga pequeño con un tiempo de carga inicial rápido ✔️
Código de aplicación seguro y privado en el servidor ✔️ ❌†
Ejecución de aplicaciones sin conexión una vez descargadas ✔️
Hospedaje de sitios estáticos ✔️
Descarga el procesamiento a los clientes ✔️

Las aplicaciones †Blazor WebAssembly pueden usar API basadas en servidor para acceder a recursos de servidor o red, y a código de aplicación privado y seguro.

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.

Compatibilidad completa con la API de .NET

Las aplicaciones Blazor Server tienen compatibilidad completa con la API de .NET, mientras que las aplicaciones Blazor WebAssembly se limitan a un subconjunto de las API de .NET. Cuando la especificación de una aplicación necesita una o varias API de .NET que no están disponibles para las aplicaciones Blazor WebAssembly, elija Blazor Server.

Acceso directo a recursos de red y servidor

Las aplicaciones Blazor Server tienen acceso directo a los recursos de servidor y red donde se ejecuta la aplicación. Como las aplicaciones Blazor WebAssembly se ejecutan en un cliente, no tienen acceso directo a los recursos de servidor y red. Las aplicaciones Blazor WebAssembly 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.

Para evitar las API basadas en servidor para las aplicaciones Blazor WebAssembly, adopte Blazor Server, que puede acceder directamente a los recursos de servidor y red.

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

Las aplicaciones Blazor Server tienen tamaños de carga relativamente pequeños con tiempos de carga iniciales más rápidos. Cuando quiera un tiempo de carga inicial rápido, adopte Blazor Server.

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

El mantenimiento del código de la aplicación de forma segura y privada en el servidor es una característica integrada de Blazor Server. Las aplicaciones Blazor WebAssembly pueden usar API hospedadas en el servidor para acceder a funcionalidades que deben mantenerse privadas y seguras. 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 Blazor WebAssembly se pueden ejecutar sin conexión, lo que resulta especialmente útil cuando los clientes no se pueden conectar a Internet. Las aplicaciones Blazor Server no se pueden ejecutar cuando se pierde la conexión al servidor. Si una aplicación se tiene que ejecutar sin conexión, la mejor opción es Blazor WebAssembly.

Hospedaje de sitios estáticos

El hospedaje de sitios estáticos es posible con las aplicaciones Blazor WebAssembly porque se descargan en los clientes como un conjunto de archivos estáticos. Las aplicaciones Blazor WebAssembly no necesitan que un servidor ejecute código del lado servidor para descargarse y ejecutarse. Las aplicaciones Blazor WebAssembly se pueden entregar mediante una red de entrega de contenido (CDN) (por ejemplo, Azure CDN). Si el hospedaje estático es un requisito de la aplicación, seleccione Blazor WebAssembly.

Descarga el procesamiento a los clientes

Las Blazor WebAssembly aplicaciones se ejecutan en clientes y, por tanto, descargan en ellos el procesamiento. 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.

Recursos adicionales