The edge, deliberately constrained.
EdgeHandler is one of the seven canonical execution surfaces — but it's the most restricted by design. Edge runs as a constrained worker variant (--mode edge, nodejs-edge runtime family, EdgeContext surface). Build-time validation blocks entity / event / workflow imports. Runtime BridgeCapabilityEnforcer.ForSurface(EdgeHandler) refuses anything off-tier. Hot business logic belongs in core handlers — never at the edge.
Low-latency, stateless. Pre-checks, not business logic.
Request shaping
Rewrite headers, normalize paths, A/B route, geo-route, language-detect — work that needs to land before the request reaches your core handlers.
Geo / latency routing
Pick the closest region. Route by user identity. Pre-resolve traffic to the right downstream — under tens of milliseconds, before TLS-to-origin.
Auth pre-checks
Pre-validate tokens, reject obviously-bad sessions, rate-limit hot paths. Final auth runs in core handlers — but the edge sheds load before it hits them.
Cache mediation
Read from CDN edge cache. Vary by canonical surrogate keys. Issue conditional revalidations through governed connections (edge-tier only).
Three-layer enforcement
Type-level: EdgeContext exposes only edge-tier methods. Compile-time: ValidateEdgeImportsAsync rejects forbidden imports. Runtime: BridgeCapabilityEnforcer refuses off-tier calls. No bypass.
What you cannot do
Read or write entities. Start workflows. Publish canonical events. Call non-edge-tier governed connections. The constraints are not lazy — they're load-bearing.
Type · compile · runtime
No durable state at the edge
EdgeContext, not full ctx
Forbidden — belongs in core
Edge that cannot drift.
Write the pre-check. Vadyl validates imports at build time, enforces the capability surface at runtime, and refuses anything off-tier. Hot business logic stays where it belongs.