Arquitectura orientada a eventos para PWA
Fecha de publicación: 2021-12-30Al estudiar los Server-Sent Events, tarde o temprano aparece la arquitectura orientada a eventos (EDA). En realidad, EDA es natural en las aplicaciones web: la usamos casi sin notarlo cuando añadimos comportamiento JavaScript al HTML.
<button onclick="myFunction()">Click me</button>La interacción entre el navegador y la persona usuaria se basa en eventos, por lo que este modelo resulta intuitivo para cualquier desarrollador web.
También es familiar el modelo navegador-servidor: el navegador envía una solicitud y recibe el resultado de la acción.
Esta es la esencia de HTTP: enviar una solicitud y recibir un resultado.
En 2004, Ian Hickson propuso extender la respuesta del servidor en el tiempo, creando un flujo y procesando el resultado por partes a medida que llega la información. De esa idea nació Server-Sent Events.
El servidor puede ahora transmitir información al cliente como flujo. Desde EDA, el servidor es el productor, el navegador es el suscriptor y la conexión HTTP más el código en ambos extremos forman el mecanismo o cola de eventos.
Este diseño exige tratamiento asíncrono y tolerancia a la pérdida de eventos individuales. Por ello resulta natural un flujo de vuelta: solicitudes del navegador que confirman la recepción de los eventos del servidor.
Las confirmaciones se pueden enviar con POST a un servicio común, indicando el ID del evento. Pero eso no resuelve por sí solo las pérdidas: la confirmación también puede perderse. La aplicación debe tolerar un mensaje ausente. Si no llega una reacción esperada a tiempo, reenvía el evento; cada suscriptor decide si ya lo trató o no lo recibió.
La propuesta interesante es usar ese canal de confirmación como un SSE invertido y enviar mensajes del navegador al servidor también de forma asíncrona. En vez de muchos servicios síncronos para acciones distintas, la aplicación tiene dos canales: uno directo para mensajes del navegador y otro de vuelta para eventos del servidor.
Este modelo encaja bien con PWA móviles que deben funcionar sin conexión. Mantienen datos de trabajo en localStorage o indexedDb y los intercambian con el servidor cuando es posible. La API web puede reducirse a dos servicios: abrir el canal de eventos del servidor e informar un evento del navegador.
En aplicaciones de este tipo, REST, GraphQL y gRPC dejan de ser el centro del diseño. No afirmo que EDA los sustituya: para PWA móviles que pasan constantemente entre offline y online, los flujos de eventos pueden encajar mejor; para aplicaciones web con conexión estable, las tecnologías clásicas de petición-respuesta siguen siendo más previsibles.