Hace unos días tuvimos una interesante sesión sobre Blazor viéndolo a vista de pájaro, es decir, qué es, qué me aporta, en qué se parece y se diferencia de otras tecnologías, por qué me interesa....
Durante la sesión, en YouTube, alguna gente nos pidió que explicásemos con un vídeo cómo funciona Blazor Server "por debajo", es decir, cómo puede hacer para gestionar en el servidor los eventos y todo lo que ocurre en el cliente sin necesidad de recargar la página. La entrevista no era el momento, así que prometimos colgar un vídeo explicativo sobre ello, y es justo lo que hacemos ahora.
El siguiente vídeo, en realidad, está sacado de nuestro potente curso sobre Blazor y es, de hecho, uno de los primeros del curso, cuando se está presentando la tecnología. Esperamos que esto disipe las dudas sobre qué pasa con Blazor Server "por debajo del capó" 😊
Os dejamos también la transcripción:
En este video vamos a ver cómo funciona una aplicación Blazor Server. Para ello tengo aquí una aplicación muy sencilla ya creada. De momento no te preocupes cómo la he creado ni cómo tienes que hacer para ponerla en marcha. Simplemente vamos a centrarnos en la parte general de cómo funciona y luego ya estudiaremos todo esto.
Esta aplicación es muy sencilla. Tienes simplemente tres páginas: esta que es un Hola mundo, esta es un contador que cada vez que pulsamos el botón aumenta este valor, y otra que se trae unos datos, en este caso de previsión del tiempo. Si te fijas, cada vez que navegamos por cualquiera de estas pestañas que tiene en realidad, aunque aquí cambia la ruta, no se está recargando la página. Ya ves que no aparece ningún indicador de que se está recargando. Es decir, es una SPA, una Single Page Application.
Podemos verlo muy fácilmente si sacas las herramientas del desarrollador usando CTRL+ Mayúsculas + I o F12 y ves aquí, en la pestaña Network, que ya tengo seleccionada. Si ahora recargo la página desde el principio para que vuelva a cargar y aparezcan aquí todos los recursos que se descarga y podamos ver qué ocurre, vemos que cada vez que cambio de pestaña, realmente aquí no se carga nada más. Es decir, se carga una primera vez la aplicación y el resto del tiempo no descarga ningún otro recurso estático más. De todo esto que se descarga, la mayoría de lo que ves aquí son elementos de la propia página. Por ejemplo, la hoja de estilos de Bootstrap, que es lo que se usa para esta plantilla, más la hoja de estilos específica con algunos detallitos estéticos y fuentes y poco más.
Las dos peticiones más importantes que hay aquí son BlazorServer.js, que es un archivo de JavaScript que podemos ver aquí. Por defecto viene minimizado, pero si le damos aquí podríamos ver su código, mejor formateado. De todas formas, aquí no vamos a entrar porque esto es algo cambiante, algo que viene en el propio framework Blazor y que puede cambiar en cualquier momento. Este archivo lo importante es saber que es el que se encarga de el mantenimiento del Estado y toda la comunicación con el servidor, para cualquier cambio que podamos hacer. Y la otra petición de verdad que nos interesa es el web socket que se abre entre el cliente y el servidor, que es este de aquí, pero ni siquiera tenemos que buscarlo porque gracias a las herramientas del desarrollador de cualquier navegador moderno podemos venir aquí y filtrar solo por web sockets exclusivamente.
En este caso tenemos este web socket, que es el que hace la comunicación entre cliente y servidor. Si yo ahora me cambio de página y pulso, por ejemplo, este botón, vamos a ver que dentro de esta web socket hay una serie de mensajes que podemos ver aquí que se están intercambiando. Estos son los mensajes que hemos intercambiado desde que cargué la página, que como vemos son muy pequeñitos, de 3 bytes, 349 bytes, 623 el más grande... y que constantemente se están produciendo. Lo que voy a hacer es borrar esto, y voy a pulsar de nuevo el botón para ver qué está pasando exactamente.
Si le doy a "Click me", vemos que hay tres mensajes y se ha incrementado este contador. ¿Qué ha ocurrido aquí? Bueno, el primer mensaje es el clic. Se notifica al servidor a través de un mensaje que se ha producido un clic. Si vemos aquí el contenido de este mensaje, en cualquier caso es muy pequeñito. Vemos que hay una llamada, un mensaje específico a dispatchBrowserEvent, que se está mandando al servidor y dentro de éste se manda toda la información sobre los eventos y analizamos un poquito de esto. Vemos que es un evento de ratón, que es un clic que nos manda la posición en donde estaba la pantalla: ScreenX, ScreenY, si estaba pulsada la tecla de control, etc, etc
El segundo mensaje es simplemente una respuesta del servidor. Fíjate que aquí tiene una flecha hacia abajo y aquí tiene hacia arriba, es decir, este se envía y se recibe. Donde en este caso se manda una instrucción de renderizado con los cambios que hay que realizar sobre la interfaz de usuario. En este caso es un cambio muy sencillo, que es poner un 2 aquí en el contador y que de hecho podemos ver aquí. Y finalmente hay un tercer mensaje que es este "Render complete" que se envía desde el cliente al servidor para indicar que el renderizado se ha realizado, es decir, todo el tiempo.
Nuestra aplicación se está comunicando con el servidor a través de ese web socket con mensajes muy pequeñitos que están coordinando cliente y servidor, las acciones que se hacen en el cliente y instrucciones que se reciben del servidor para actuar sobre la interfaz del cliente.
Todo esto se recarga en la página y utilizando un protocolo muy eficiente y muy rápido como es web sockets y además bidireccional. Como estamos viendo.
Además, otra cosa interesante es que podemos ver que este web socket es una conexión persistente. Todo el rato está funcionando, salvo si perdemos la conexión. Por ejemplo, vamos a simular que se pierde la conexión. Bueno, en este caso no puedo venir aquí a "on line" y ponerlo "offline", porque aunque esto funciona con conexiones normales, voy a volver a mostrar todas. Si aquí hiciera alguna petición normal por HTTP, al poner esto offline no se podría realizar, pero en el caso concreto de los web sockets sí que se siguen realizando. Si pulsa el botón voy a borrar la lista de mensajes. Si pulsa el botón, vemos que sigue funcionando, entonces esto no me vale para probar una desconexión y lo que voy a tener que hacer es parar, en este caso Internet Information Server Express, que está aquí funcionando, a mostrar las aplicaciones y que haya una aplicación con dos puertos HTTP y HTTPS.
Ahora estamos conectados al HTTPS. Es un certificado local, por eso dice que no es seguro, porque tengo que confiar explícitamente en él. Vale, bien, lo que voy a hacer es pararla. Aquí voy a parar directamente todo. En cuanto lo paro, vamos a ver que dice que se está intentando reconectar al servidor. Ya no hay más mensajes, vale, y de hecho si que hay nuevas peticiones HTTP en concreto XHR, es decir, por AJAX, intentando conectarse, lo va a intentar durante unos cuantos segundos y varias veces, y cuando no sea capaz de conectar va a dar un fallo y me va a pedir que me reconecte manualmente cuando crea que vuelvo a tener conexión, en este caso de cara al navegador. Es como si ya no existiera una conexión a Internet. Vamos a esperar un poquito... Ahí está. Me dice que ha fallado la conexión y que debo reintentar.
Bien, para resumir, lo que tenemos que saber es que una aplicación Blazor Server lo que hace es una parte, está en un servidor y una parte está en el cliente y ambas están en comunicación continua. Cualquier cosa que ocurra en el cliente y que sea reseñable para el servidor se va a transmitir hacia el servidor y el servidor va a transmitir de vuelta lo que tiene que hacer el cliente, de manera que siempre tenemos una única página. Es una Single Page Application con una comunicación a través de web sockets todo el tiempo por detrás. Si esa conexión se pierde, pues la aplicación deja de funcionar como en cualquier aplicación web que en un momento dado deje de tener conexión. Este es el funcionamiento básico de este tipo de aplicaciones.
Fecha de publicación: