Collapse it

The domain from the previous page runs nowhere yet: it is pure potential. Choosing where it runs is a single, separate act, adding an adapter to the application manifest. The manifest is the only file that knows about platforms.

#The manifest names the context

Application.ts is the manifest. Add the Node HTTP adapter and the Tasks domain becomes a running HTTP service. Notice that Tasks.ts is not touched and not even imported here: the adapter finds your handlers through the Blueprint.

import { StoneApp } from '@stone-js/core'
import { Routing } from '@stone-js/router'
import { NodeHttp } from '@stone-js/node-http-adapter'

@NodeHttp()   // the context: serve the domain over HTTP on Node
@Routing()
@StoneApp({ name: 'tasks' })
export class Application {}

import { defineStoneApp } from '@stone-js/core'
import { routerBlueprint } from '@stone-js/router'
import { nodeHttpAdapterBlueprint } from '@stone-js/node-http-adapter'

export const App = defineStoneApp(
  { name: 'tasks' },
  [routerBlueprint, nodeHttpAdapterBlueprint]
)

npm run dev
curl localhost:8080/tasks           # []  (empty list)
curl -X POST localhost:8080/tasks -d 'title=Ship it'
curl localhost:8080/tasks           # [{ "id": "...", "title": "Ship it", "done": false }]

#Change the where, keep the what

To run the same domain somewhere else, you change the adapter, not the domain. Swap @NodeHttp() for @Fetch() and it deploys to Cloudflare, Deno, Bun, Vercel or Netlify. Swap it for @AwsLambdaHttp() and it is a Lambda. The handler and service stay byte-for-byte identical.

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

npm run build emits a single self-contained artifact in dist/, with no node_modules to carry. That one artifact drops onto any JavaScript runtime; the adapter you chose decides which shape it takes.

• Node servers and Docker containers.
• Serverless: AWS Lambda, Azure Functions, and the like.
• Edge: Cloudflare Workers, Vercel Edge, Deno Deploy, Bun.
• Static hosts / CDNs for frontend (CSR/SSG) builds.