HTML sobre WebSockets

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, aunque también se denomina HTML over the Wire, Hotwire o solo HTML over 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.

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.

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.

2. Petición de componente

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

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.

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, esta Docketizado a un comando de distancia para arrancarlo.

¿Cuáles son sus ventajas?

• Solo hay un motor de renderizado, simplificando la complejidad.
• Conexión directa con la base de datos, evitando la creación de un API.
• Real-time, los clientes reciben los cambios tan rápido como sea posible.
• Mayor velocidad ya que el protocolo WebSocket es más rápido que HTTP. Fuente: starkoveflow
• Apropiado para conexiones lentas. Fuente: browsee.
• Crear un SPA sin apenas JavaScript o el uso de frameworks complejos como ReactJS, Angular o VueJS.
• Excelente SEO, con esta estrategia es muy natural hidratar HTML o crear páginas que pueden ser leídas por motores de búsqueda.

¿Cuáles son sus inconvenientes?

• El servidor necesitará más recursos al tener que dejar un WebSocket abierto por cliente.
• PHP no es compatible con el protocolo WebSocket, a no ser que utilices extensiones o frameworks como Ratchet.
• Poca documentación o ejemplos en la red.
• 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.
• PHP: Livewire (no es real ya que usa AJAX en lugar de WebSockets, pero las bases son las mismas).

Apuntes finales

No creo que sea la solución definitiva, pero merece ser escuchado. Es llamativo su creciendo adopción y aparición de herramientas en torno al concepto. Cada lenguaje posee su propio clon de LiveView, y es una promesa de futuro por una corriente de desarrolladores muy importante. A nivel personal se sorprendió lo poco conocido que es, posiblemente a causa del poderoso ecosistema de JavaScript y el poco contenido formativo. Sin embargo es todo un placer no estar en la carrera de fondo que supone el Front-End para no quedarse desactualizado, y poder centrarte en el lenguaje de servidor.

En serio, ¿qué puedes perder por probarlo?