Dentro del Runtime SDK: por qué importa el boot determinista
Un recorrido por la clase Loom — la máquina de estados finita que gobierna tu proceso de BOOT a SHUTDOWN.
La mayoría de los outages de Node.js que hemos depurado comparten una causa raíz que nunca aparece en el stack trace: el orden de inicialización. El servidor HTTP aceptó tráfico antes de que el pool de base de datos estuviera listo. El consumidor de la cola arrancó antes de que terminara de cargar la config. Funciona en el segundo restart, y nadie sabe por qué.
El Link Loom SDK existe para eliminar esa clase de bug. La clase Loom no es un framework web — es un runtime host. Cuando llamas ignite(), una máquina de estados finita recorre la misma secuencia en cada boot:
- Módulos core — contenedor de dependencias, logging, settings, utilities.
- Infraestructura — database, storage, push, observabilidad.
- Adapters — HTTP (Express 5), bus de eventos, funciones, streams, workers.
- Tráfico — solo ahora escucha el servidor.
SIGINT y SIGTERM desmontan en reversa, así que una evicción del pod nunca deja una conexión a medio abrir.
El grafo de dependencias es el API
Cada servicio, ruta y modelo recibe el mismo objeto dependencies estructurado en su constructor — logger, config, cliente de base de datos, bus de eventos, utilities. Nada importa un singleton; nada toca un global. Esa única convención se paga sola tres veces: los tests mockean un objeto, las trazas de producción fluyen por un contexto, y el code review lee un solo patrón.
El transporte es un detalle
Un UserService en Loom no sabe que HTTP existe. El adapter de API lo llama para un POST; el adapter de eventos lo llama cuando llega un evento de user_signup; un worker lo llama desde un job en background. La misma clase, tres transportes, cero reescrituras.
El SDK es Apache-2.0 — léelo, forkéalo, córrelo en tu propio metal. El cloud lo hace más cómodo; nunca lo hace obligatorio.
