Explicit DI, no decorators
Every module receives `dependencies` in its constructor. Mock it in tests, trace it in production, read it in code review.
Developers
Five minutes to a running service.
The runtime is open source and the quickstart is honest: install one package, write one file, run it. Everything else — workers, vault, apps — composes on top when you need it.
Quickstart
Ignite your first service.
$ npm i @link-loom/sdkconst { Loom } = require('@link-loom/sdk');
const loom = new Loom({ root: __dirname, name: 'my-service' });
const main = async () => {
const dependencies = await loom.ignite();
dependencies.console.success('Service is running!');
};
main(); Built for engineers
No magic. Contracts.
Lifecycle you can reason about
ignite() runs the same sequence every boot: core modules, infrastructure, adapters, then traffic. SIGTERM tears down in reverse.
Workers when you need muscle
Extend BaseWorker, spawn it from the runtime, get isolation and total memory reclaim for free.
Adapters, not rewrites
HTTP, events, functions, streams — your service logic stays transport-agnostic and every transport is a config away.
Vault-backed environments
Local .env for your laptop, Cloud Vault runtime fetch for everything else. Same code both ways.
CLI scaffolding
link-loom create --name my-service bootstraps the canonical project layout so every repo looks familiar.
Open source
View on GitHub Read the code you run.
The SDK lives in the open on GitHub. The runtime your platform depends on should be something you can audit, fork and contribute to — so it is.