Stone.jsDocs
Paradigm

Foundations

The ephemeral context

Each time the domain is applied to an intention, it runs inside a container built for that one event and thrown away afterwards. Nothing you resolve leaks into the next request. This single rule removes most of the state bugs that plague long-lived servers.

#One container per event

The principle

Shared mutable state across requests is the source of the hardest server bugs: leaked user data, order-dependent behaviour, memory that grows request by request. If each event gets its own isolated scope, those bugs cannot form.

In Stone.js

For every incoming event, the kernel spins up a fresh service container, resolves your handlers and services into it, runs them, and discards it. What you register as a singleton lives for that one event, not for the process.

Nothing survives the request that should not. The blank slate is the default, not a discipline you enforce.

#What stays, what goes

The adapter is the only long-lived thing: it holds the connection to the platform and builds a new context per cause. The Blueprint is built once and read-only. Everything else, the container and everything in it, is per-event.

app/Tasks.tsts
@EventHandler('/tasks')
export class TaskController {
  // Built fresh for THIS event. Fields here are safe: they cannot bleed
  // into another request, because this instance does not outlive the event.
  private readonly tasks: TaskService
  constructor ({ tasks }: { tasks: TaskService }) { this.tasks = tasks }
}

#Why serverless fits perfectly

The ephemeral model and serverless runtimes are made for each other. A Lambda or a Worker already gives you a short-lived execution per invocation; the per-event container matches that grain exactly. There is nothing long-lived to warm except the adapter, so the domain pays no tax for running on the edge.


Stone.js

Your app exists in every runtime. Until you run it.

An open-source project by Stone Foundation
Created by Mr. Stone (Evens Pierre)