Edge & Serverless

This is the context that most punishes coupling. Every platform has its own handler signature, its own request object, its own cold-start rules. A domain welded to any one of them cannot follow the industry as it moves. A domain that deferred the where just ships.

#The industry standardised. So did we.

@stone-js/fetch-adapter is a single adapter built on the Web-standard Request/Response (WinterCG). It normalises the cause on any fetch-based runtime into the same IncomingEvent your domain already reads. AWS Lambda has its own event shape, so it gets its own adapter, and both stack.

#Collapse it onto the edge

The Tasks domain does not appear here, because it does not change. Only the manifest does.

import { StoneApp } from '@stone-js/core'
import { Routing } from '@stone-js/router'
import { Fetch } from '@stone-js/fetch-adapter'
import { AwsLambdaHttp } from '@stone-js/aws-lambda-http-adapter'

@Fetch()          // Cloudflare, Deno, Bun, Vercel, Netlify (Web-standard)
@AwsLambdaHttp()  // ...and AWS Lambda, stacked
@Routing()
@StoneApp()
export class Application {}

import { defineStoneApp } from '@stone-js/core'
import { routerBlueprint } from '@stone-js/router'
import { fetchAdapterBlueprint } from '@stone-js/fetch-adapter'
import { awsLambdaHttpAdapterBlueprint } from '@stone-js/aws-lambda-http-adapter'

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

npm run build            # build for your target
# deploy the output to Cloudflare, Deno Deploy, Vercel, Netlify, or Lambda
# the handlers are byte-for-byte the same across all of them

#Why this is the payoff of the whole model

This is where it all pays off. The domain never named a platform, so moving from a Worker to a Lambda to a Deno isolate is a deployment decision, taken long after the logic was written, and reversible.