Skip to main content
Estado: Propuesto (RECONSTRUCCIÓN — requiere validación) · Fecha: 2026-08-17 (reconstruido) Refs: ../constitution/founding-constitution.md
Traducción. Autoritativo: ../../adr/adr-007-pusher-realtime.md. ⚠️ Reconstruido a partir del material que tenemos, no recuperado. Etiquetas: [derived] tiene respaldo en el repositorio · [inferred] es deducido · [proposed] es un hueco que llené.

Contexto

Una consola mostrando profundidad de cola en vivo, un portal de member actualizando un saldo, un operador mirando una importación — todos necesitan push del servidor al cliente. Las opciones son gestionadas (Pusher, Ably, Supabase Realtime) o WebSockets auto-hosteados, que significa hacerse cargo del estado de conexión, del escalamiento y de la reconexión. [inferred]

Decisión

Pusher Channels, con tokens firmados por nuestra API. [derived] Un cliente nunca se autentica directamente contra Pusher. Le pide a nuestra API un token firmado acotado a los canales que puede escuchar, lo que mantiene la autorización de canal dentro de nuestro modelo de permisos en vez de en un segundo modelo. [inferred] El realtime es un consumidor del outbox (ADR-004), no un camino de publicación paralelo. [derived] Todo lo que se entrega en realtime ya ocurrió y ya está registrado.

Consecuencias

  • Sin estado de conexión, sin escalar sockets de larga vida, sin lógica de reconexión.
  • La autorización de canal usa nuestros permisos, así que hay un solo modelo de autorización. − Un vendor en el camino caliente de una experiencia visible para el usuario, y un costo por conexión. − El realtime está detrás de RealtimePort (ADR-003), así que reemplazar Pusher es un adaptador — que es exactamente por qué existe el puerto. [inferred]

Lo que no pude determinar

Si Supabase Realtime se consideró y descartó, dado que Supabase ya es la base de datos. Sería la alternativa obvia y esperaría que el ADR original dijera por qué no. [proposed]