HTML sobre WebSockets

3 minutos

WebSockets sobre HTML

La forma tradicional de conseguir una SPA (Single-page Application) es dividir las responsabilidades, el Back-End sirve la información y el Front-End la dibuja dinámicamente. Tristemente implica un doble esfuerzo en el desarrollo siendo necesario la creación de 2 aplicaciones con tecnologías diferentes aumentando costes e involucrando a dos perfiles especializados. Aunque, por supuesto, es el precio que debemos pagar si queremos una web en tiempo real y que se renderice en un pestañeo. ¿O hay una alternativa? ¿Con incluso mejor rendimiento? Así es, y además es más fácil de desarrollar al trabajar con un solo lenguaje. Esta arquitectura se denomina: HTML sobre WebSockets.

Chris McCord, creador de Phoenix (el Framework más popular dentro del ecosistema Elixir), presentó en ElixirConf 2019 una tecnología llamada LiveView. En apenas 15 minutos creó un clon de Twitter que funcionaba en tiempo real sin necesidad de incorporar JavaScript renderizador o un framework popular (React, Angular, Vue…) que gestione la Vista, demostrando que era posible quedarse en el Back-End y lograr productividad con una dulce aroma a buen rendimiento. Desde entonces se ha popularizado esta solución, inspirado a otros desarrolladores para crear implementaciones de HTML sobre WebSockets en otros lenguajes. Se puede volver al Back-End pero sin renunciar a lo bueno del Front-End.

¿Cómo funciona?

Disclamer: ¡si se usa JavaScript! Su labor no es renderizar sino crear un canal de comunicación con WebSockets y situar el HTML recibido en el lugar adecuado. Además de otras tareas secundarias como animaciones, gestión de eventos, etc.

La solución de McCord es no enviar al Front-End un JSON, sino HTML que no necesite ser preprocesado. De ese modo trasladamos la carga del dibujado, y toda su lógica, al Back-End. Ya pero… ¿Cómo hacemos que el servidor nos envíe nuevo contenido de forma inmediata y sin realizar una petición? Sencillo: con WebSockets.

Repasemos el sistema tradicional de la introducción. Desde la Web hago una petición HTTP, el navegador inicia la acción, obteniendo en la respuesta un JSON con toda la información en crudo. Lo siguiente es interpretar y crear el HTML correspondiente.

Tradicional

Mientras que HTML sobre WebSockets puede ser el envío de un JSON donde se devuelve HTML/CSS/JS. O incluso puede quitar el propio envío quedando a la escucha.

Protocolo WebSockets sobre HTML

Veamos el ejemplo donde se renderiza el artículo número 2 de un blog.

1. Conectamos

Partimos con una conexión. Ya hay un tubo de comunicación entre cliente y servidor.

Conectar con WebSockets

2. Petición de componente

El cliente pide el contenido de la ruta “/articulo/2/” a través del canal.

Pedir WebSockets sobre HTML

3. Recepción de HTML/CSS/JS

El servidor genera el HTML/CSS/JS, usando el sistema de plantillas del Back-End, y lo devuelve por el canal.

Recibir WebSockets sobre HTML

4. Impresión

Por último, el Front-End lo sitúa en el lugar adecuado o asignado.

¿Dónde puedo ver una demostración?

He creado un prototipo en Django de un Blog con 100 entradas, cada artículo esta relacionado con sus respectivos comentarios. Además existe un apartado para visualizar el artículo completo, un paginador y una sección estática con algunos párrafos.

Aquí puedes ver como los cambios son reflejados en todos los clientes.

Si observáis la url, nunca se cambia de página, y… ¡aun así funciona! ¿Quieres probarlo por ti mismo? Tienes la posibilidad de levantarlo a partir del código fuente en GitHub, esta Docketizado a un comando de distancia para arrancarlo.

¿Cuáles son sus ventajas?

  • Solo hay un motor de renderizado, simplificando la tarea.
  • Real-time, los clientes reciben los cambios tan rápido como sea posible.
  • El protocolo WebSockets es más rápido que HTTP. Fuente: starkoveflow
  • Apropiado para conexiones lentas. Fuente: browsee.
  • Crear un SPA sin apenas JavaScript.
  • Excelente SEO, los motores de búsqueda adorarán la página al encontrarse solo HTML.

¿Cuáles son sus inconvenientes?

  • El servidor necesitará más recursos al tener que dejar un WebSocket abierto por cliente.
  • Poca documentación al respecto.
  • Pocos frameworks.

¿Qué Frameworks existen?

Puedes empezar por los siguientes recursos.

  • Elixir/Phoenix: LiveView.
  • Python/Django: Sockpuppet y Reactor.
  • C#/.NET: Blazor Server.
  • JavaScript: Turbo con Stimulus

Apuntes finales

No creo que sea la solución definitiva, pero merece ser escuchada. Es llamativo su creciendo adopción y herramientas que están apareciendo. A nivel personal se sorprendió lo poco conocido que es, posiblemente a causa del poderoso ecosistema de JavaScript. Sin embargo es todo un placer no estar en la carrera de fondo que supone el Front-End para no quedarte desactualizado, y centrarte en el lenguaje de servidor.

En serio, ¿qué puedes perder por probarlo?

¿Te ha gustado? Comprame un café

Comentarios

{{ comments.length }} comentarios

Nuevo comentario

Nueva replica  {{ formatEllipsisAuthor(replyComment.author) }}

Acepto la política de Protección de Datos.

Escribe el primer comentario

Tal vez también te interese...