Foundations

Adapters

The adapter is the integration dimension, the boundary between a platform and your domain. It is the only long-lived thing in a Stone.js app, and the only thing that speaks a platform's language. Everything inward is agnostic because the adapter absorbs the specific.

#Cause in, effect out

The principle

Every platform delivers work differently: an HTTP request object, a Lambda event, a fetch Request, an argv, a tool call. If each of those is translated at the boundary into one common shape, the code behind the boundary never has to learn the platform's dialect.

In Stone.js

An adapter does three things. It captures the raw cause the platform delivers, normalises it into an IncomingEvent (the intention the kernel and your domain read), and emits the kernel's response as the platform's native effect.

Capture the cause. Normalise it to an intention. Emit the effect. That is a context, in three verbs.

#Where the collapse happens

The adapter is where superposition becomes a single running application. Stack several adapters and each waits, long-lived, for its platform's cause. When one arrives, that adapter builds the per-event context, runs the kernel, and maps the result back. The decoherence, the messy translation from raw reality to clean intention, is confined here and never leaks inward.

app/Application.tsts

// Each decorator adds one adapter (one context) to the manifest.
@NodeHttp()       // captures Node's IncomingMessage
@AwsLambdaHttp()  // captures API Gateway events
@Fetch()          // captures the Web-standard Request
@Routing()
@StoneApp({ name: 'tasks' })
export class Application {}

#Long-lived by design

The adapter persists for the life of the process; everything it produces, the container and the domain instances, is per-event and discarded. This split is deliberate: it is what lets the ephemeral context stay clean while the connection to the platform stays open.