CONCEPT Cited by 1 source

Build-time vs runtime phase separation

Build-time vs runtime phase separation is the decomposition axis that splits a framework-integration problem into two temporal layers:

1. Build-time phase — what the compiler / bundler does to transform user source code into deployable artefacts, determine output locations, configure hot-reload, apply framework-specific patches.
2. Runtime phase — what the application server does at request-serving time to wire the build-time artefacts into the framework's HTTP surface (expose them as endpoints, translate request objects, enforce auth, etc.).

Canonical verbatim statement from Vercel's 2026-04-21 WDK post: "every framework integration follows the same two-phase pattern." The build-time phase "compiles your workflow and step functions into executable handler files ... handles bundling, determines where files are output, and applies any framework-specific patches needed for compatibility." The runtime phase "applies workflow client transforms and makes the handler files from the build-time phase accessible by your application's server."

Why the separation matters

Thinking in build-time + runtime phases as orthogonal axes keeps framework integrations comparable and reusable. Without it, each framework integration becomes a unique monolith ("how do I make this work with SvelteKit") and code doesn't transfer.

With it, the integration template is consistent across N frameworks — same two phases, different per-framework adapters at the bridge points:

• Build-time bridge: where do the generated handler files go? (Next.js: app/.well-known/workflow/v1; SvelteKit: src/routes/.well-known/workflow/v1; Express/Hono: virtual handlers via Nitro.)
• Runtime bridge: how does the framework discover / invoke the handler files? (File-based routing frameworks: auto-discovery by filename; bare-HTTP frameworks: Nitro injects virtual handlers at runtime.)

This is the load-bearing reason one SWC compiler plugin + one core Vite integration can serve 8 frameworks with ~90% shared code.

Contrast: directive-driven compile-time split

The build-time phase in a compiler-centric integration like WDK uses use- directive compilation markers to decide which transforms apply per function. The runtime phase is directive-unaware — the handler files it wires up are already compiled outputs. The split is deliberate: build-time plugin reads source directives; runtime adapter reads framework APIs.

Contrast: where frameworks split

The build-time-runtime split is distinct from but complementary to the file- based-routing-vs-bare-HTTP-framework taxonomy. The taxonomy tells you how the framework exposes handlers (the runtime bridge); the phase split tells you how to decompose your integration code regardless of taxonomy.

Seen in

• sources/2026-04-21-vercel-inside-workflow-devkit-how-framework-integrations-work — canonical wiki statement. WDK's load-bearing thesis is that "every framework integration follows the same two-phase pattern" — build-time handler generation + runtime handler exposure, with framework-specific patches at the bridge points.

Related

• patterns/two-phase-framework-integration-pattern — the reusable template this concept names.
• patterns/swc-plugin-three-mode-transform — the build-time mechanism WDK uses.
• concepts/use-directive-as-compilation-marker — the source-level marker the build-time phase reads.
• concepts/file-based-routing-vs-bare-http-framework-taxonomy — the framework taxonomy that shapes the runtime bridge.
• systems/vercel-workflow — the 2026-04-21 instance.