TeqFW: eventos transfronterizos

Fecha de publicación: 2022-02-02

TeqFW se dirige a PWA móviles que deben sobrevivir a un acceso a Internet poco fiable. El intercambio clásico solicitud-respuesta no encaja en todas las interacciones, por lo que frontend y backend se coordinan mediante eventos. Este artículo describe el patrón para transferirlos a través de la frontera de red.

Dos canales unidireccionales

Cada cliente de navegador tiene un canal para eventos hacia servidor y otro para eventos de vuelta. Los navegadores no aceptan conexiones entrantes como servidores, por eso ambos canales los inicia el navegador:

• navegador → servidor: una solicitud POST estándar;
• servidor → navegador: EventSource / Server-Sent Events (SSE).

Los dos canales son unidireccionales, de publicador a suscriptor. La respuesta POST solo confirma recepción, no es una respuesta de negocio síncrona; SSE no ofrece respuesta inversa en el mismo canal.

Un evento que nace en un lado y se maneja en el otro es transfronterizo.

Colas de eventos

Las PWA que funcionan offline necesitan buffers para mensajes que no pueden cruzar la red ahora mismo.

Cada lado tiene un Event Bus que notifica a suscriptores locales de eventos propios y remotos. Un Event Portal mueve mensajes transfronterizos al bus del otro lado. Si no se puede entregar, una Events Queue persiste el mensaje hasta volver la conectividad. El esquema es simétrico en ambas direcciones.

Vigilar conectividad

El frontend establece las conexiones. Si navigator.onLine indica que está offline, almacena los mensajes salientes en una cola respaldada por IndexedDB. Si hay Internet, intenta abrir el canal SSE con backend. Si SSE no se establece, considera que el servidor no está disponible y conserva los mensajes.

Los reintentos pueden empezar cada pocos segundos y aplicar backoff. Cuando ambas direcciones están disponibles, se transfieren colas de navegador y servidor. Esto se parece deliberadamente más a datagramas que a solicitudes síncronas: un mensaje puede quedar obsoleto o perderse. La lógica de negocio debe reconciliar estado, confirmar mensajes críticos de forma asíncrona, reintentar cuando proceda y hacer los manejadores idempotentes. Una cola por sí sola no garantiza entrega exactamente una vez.

UUID del frontend

Un backend sirve muchas instalaciones de navegador. Diferentes navegadores, perfiles o dispositivos tienen cookies, cachés e IndexedDB separados aunque carguen la misma PWA. Durante la instalación, una aplicación Teq genera un UUID de frontend y lo guarda en almacenamiento del navegador.

El backend usa ese UUID para dirigirse a un frontend concreto y cerrar una conexión SSE duplicada si, por ejemplo, un cambio de red deja una conexión antigua colgada. Es un identificador de instalación, no un ID de sesión ni un token; autenticación y autorización siguen siendo responsabilidades separadas.

Estructura del mensaje

Un mensaje transfronterizo es JSON con datos de negocio y metadatos de enrutamiento:

{
  "data": {},
  "meta": {
    "name": "Event_Name",
    "uuid": "message UUID",
    "published": "2022-01-31T13:11:51.628Z",
    "frontUUID": "frontend UUID"
  }
}

data contiene el negocio. meta identifica tipo, mensaje, instante UTC y frontend emisor o destino. Permite enrutar, deduplicar, expirar y observar.

Resumen

Las aplicaciones web orientadas a smartphone deben operar con conectividad intermitente. La comunicación por eventos con colas persistentes puede ser más realista que fingir que cada solicitud tiene respuesta estable. El precio es definir entrega explícitamente: metadatos en mensajes, manejadores tolerantes a reintentos y pérdidas, y sincronización de estado al reconectar.