Inside the Runtime SDK: why deterministic boot matters
A tour of the Loom class — the finite state machine that governs your process from BOOT to SHUTDOWN.
Most Node.js outages we have debugged share a root cause that never appears in the stack trace: initialization order. The HTTP server accepted traffic before the database pool was warm. The queue consumer started before the config finished loading. It works on the second restart, and nobody knows why.
The Link Loom SDK exists to delete that class of bug. The Loom class is not a web framework — it is a runtime host. When you call ignite(), a finite state machine walks the same sequence on every boot:
- Core modules — dependency container, logging, settings, utilities.
- Infrastructure — database, storage, push, observability.
- Adapters — HTTP (Express 5), event bus, functions, streams, workers.
- Traffic — only now does the server listen.
SIGINT and SIGTERM tear down in reverse, so a pod eviction never strands a half-open connection.
The dependency graph is the API
Every service, route and model receives the same structured dependencies object in its constructor — logger, config, database client, event bus, utilities. Nothing imports a singleton; nothing reaches into a global. That single convention pays for itself three times: tests mock one object, production traces flow through one context, and code review reads one pattern.
Transport is a detail
A UserService in Loom does not know HTTP exists. The API adapter calls it for a POST; the events adapter calls it when a user_signup event lands; a worker calls it from a background job. Same class, three transports, zero rewrites.
The SDK is Apache-2.0 — read it, fork it, run it on your own metal. The cloud makes it more comfortable; it never makes it mandatory.
