@rasenganjs/futon Adapter Patterns

When to Activate

• Getting a Futon app listening on an actual port
• Choosing between @rasenganjs/runtime's platform adapters (Node/Bun/Workerd) and futon's own toExpressHandler/toWinterCgHandler bridges
• Mounting a Futon app inside an existing Express app
• Deploying a Futon app to Cloudflare Workers, Deno, or another WinterCG-style (req, env, ctx) runtime
• Wiring dev-mode file watching or graceful shutdown around a Futon app

The Core Pattern

A Futon instance is transport-agnostic — it only knows .fetch(request, runtime) => Promise<Response>. Something else has to bind that to an actual server. That "something else" is always one of:

1. A RuntimeAdapter from @rasenganjs/runtime (Node, Bun, or Workerd) — the primary, full-featured path (dev server, watch, assets, env loading, lifecycle)
2. A bridge adapter from @rasenganjs/futon itself — toExpressHandler (mount inside an existing Express app) or toWinterCgHandler (adapt to a raw (req, env, ctx)-style runtime with no RuntimeAdapter machinery)