Gestionar estado complejo con flujos de datos reactivos usando Datastar, Glimmer, Domino y Ebb
Una arquitectura basada en cuatro bloques – Datastar, Glimmer, Domino y Ebb – permite mantener la consistencia de aplicaciones grandes sin fugas de memoria ni estados inconsistentes.
La publicación de Yogthos describe una solución para aplicaciones que ya no caben en un simple modelo reactivo. Cuando la lógica de negocio se vuelve extensa y los datos entran y salen de servicios externos, el mantenimiento de la coherencia se vuelve complicado. La propuesta se apoya en cuatro componentes que se integran de forma natural.
Datastar y Glimmer proporcionan la capa UI reactiva. Glimmer, disponible en GitHub, expone átomos que se actualizan al cambiar el estado, mientras que Datastar facilita la sincronización entre el cliente y el servidor sin escribir código de boilerplate.
Domino actúa como motor de flujo de datos transaccional. Cada regla de negocio se asocia a una ruta del documento de estado y se dispara cuando su entrada cambia. Las reglas se encadenan dentro de una transacción que produce un nuevo documento, garantizando que todas las derivaciones se calculen de forma atómica. El repositorio de Domino está en GitHub.
Ebb funciona como bus de servicios en los bordes de la aplicación. Recibe eventos externos (bases de datos, APIs, correo, generación de PDFs) y los entrega a Domino; a su vez, los efectos generados por Domino fluyen de nuevo a través de Ebb hacia los sistemas externos. Ebb es una reimplementación en Clojure de la API de Missionary, pero sobre fibras Jolt, lo que permite pausar la ejecución en cualquier profundidad de pila.
El flujo de datos sigue este patrón: entrada del usuario → Glimmer → Ebb → Domino → cálculo de valores derivados → Glimmer actualiza la UI. La dirección inversa, desde eventos externos hacia la UI, recorre Ebb → Domino → Glimmer. Esta separación mantiene la lógica de negocio aislada de los detalles de infraestructura.
Una característica destacada es la gestión de back‑pressure mediante el protocolo bidireccional de Missionary. En el ejemplo del dashboard, el autor muestra dos canales: el primero usa m/observe + m/relieve para descartar valores obsoletos cuando el consumidor se retrasa; el segundo usa m/via m/blk para bloquear al productor hasta que haya demanda, evitando pérdidas de datos. Ambas estrategias se implementan con fibras reales, lo que supera la limitación del operador ? de Missionary, que solo podía pausar dentro del cuerpo lexical.
Esta arquitectura elimina fugas de recursos típicas de aplicaciones reactivas: cada recurso se aloca bajo demanda y se libera al desmontar el componente que lo consumió. No hay websockets huérfanos ni hilos zombies, y la supervisión basada en grafos acíclicos garantiza una limpieza determinista.
En la práctica, la combinación de estos bloques permite construir dashboards, paneles de control o cualquier UI que necesite actualizarse en tiempo real mientras interactúa con múltiples servicios externos sin comprometer la consistencia ni la performance.
