El runtime reactivo: eventos, functions y streams

Un runtime que solo responde peticiones HTTP es medio runtime. La otra mitad es todo lo que pasa entre peticiones: el evento que se propaga a tres servicios, el reporte que corre cada mañana a las nueve, la barra de progreso que un usuario mira mientras un build transmite. Link Loom entrega las tres cosas como adapters de primera clase.

Dos capas de eventos — nunca un monolito distribuido

El sistema de eventos está partido en dos a propósito, para que el acoplamiento local nunca se filtre al acoplamiento de dominio:

Capa 1 — el bus interno. Un EventEmitter in-process medido en microsegundos. Cuando tu UserService emite user.created y tu lógica de notificaciones reacciona en el mismo proceso, no hay broker involucrado. Reactividad sin infraestructura.

Capa 2 — el broker, patrón Kafka. Para todo lo que cruza una frontera de proceso, Loom adopta la arquitectura producer–broker–consumer: los producers emiten eventos con un topic y una routing key; el broker (RabbitMQ, Redis Streams) garantiza durabilidad, ruteo y backpressure; los consumers procesan y hacen ack — o nack, y el mensaje se reintenta. Ningún lado sabe que el otro existe. Esa transparencia de ubicación es lo que permite que un cluster de nodos sirva un chat en tiempo real donde el mensaje entra por el nodo 1 y sale por el nodo 2.

El contrato vive en un manifiesto declarativo — src/events/index.js declara cada topic al que tu servicio produce y cada evento que consume. Tu IO de eventos se revisa en un archivo, en un PR.

Functions — el job runner que dejas de escribir

Todo backend desarrolla tres tipos de lógica que no es una petición, y el adapter de Functions los nombra:

• Timed functions reemplazan el crontab externo con un scheduler con corrección de drift: se alinea al próximo startAt con un delta preciso y luego fija la cadencia. Digests diarios, agregaciones por hora, jobs de limpieza — una clase con un método run().
• Startup functions custodian el boot. El modo bloqueante (atTime) se niega a aceptar tráfico hasta que corran las migraciones o responda la base de datos; el modo async (onServerLoaded) siembra datos y calienta cachés con el servidor ya arriba. «Funciona después del segundo restart» deja de ser un género de bug.
• Cache functions son singletons con estado — stores en memoria estructurados para feature flags, datos de referencia o un modelo de ML cargado, sin contaminar globals.

Streams SSE — progreso que puedes mirar

El adapter de streams empuja server-sent events a cualquier cliente con HTTP plano. Es el caballo de batalla silencioso detrás de las propias superficies de la plataforma: los builds en cloud de App Studio transmiten sus fases en vivo al editor a través de este adapter exacto. Cuando tu producto necesite una barra de progreso, un log en vivo o una métrica que late, el stream ya viene en la caja.

Tres sistemas, un grafo de dependencias, cero frameworks extra. Eso significa «reactivo» aquí: no un ensayo de paradigmas — infraestructura que reacciona.