PATTERN Cited by 2 sources

Middleware Worker adapter

Middleware Worker adapter is the pattern of placing a thin edge-compute Worker in front of — or in between — an existing application and a set of platform-native services, so the Worker owns every cross-boundary concern (auth, routing, provider API shape, protocol adaptation, secret injection, observability) while the application stays unmodified.

The application keeps talking to whatever interfaces it was designed for (local filesystem, local Chromium, local Anthropic, local auth); the Worker re-projects each of those interfaces onto a managed platform service. The Worker is architecturally an adapter, not a feature — it exists only to let an unchanged application run in a new substrate.

Shape

┌─────────────┐     ┌───────────────────┐     ┌────────────────────┐
│ Client      │───▶│ Worker (middleware)│───▶│ Platform services   │
│             │     │ · auth gate        │     │ · LLM gateway       │
└─────────────┘     │ · API router       │     │ · headless browser  │
                    │ · protocol proxy   │     │ · object storage    │
┌─────────────┐     │ · secret injection │     │ · KV / D1 / DO     │
│ App runtime │◀──▶│ · observability   │◀──▶│ · everything else   │
│ (container/ │     └───────────────────┘     └────────────────────┘
│  sandbox)   │
└─────────────┘

The application speaks its native APIs (local CDP, local fs, local env vars) to the Worker, which translates those into the platform's native surfaces.

Why a Worker specifically

• Ubiquitous reach — a Worker is addressable from browsers, chat clients, AI agents, and application runtimes alike.
• Low-latency composition — in-Cloudflare calls to AI Gateway, Browser Rendering, R2, KV, D1, Durable Objects are same-network.
• Cheap per-concern isolation — new concerns (rate limiting, audit logging, per-user tagging) bolt on as Worker middleware without touching the application runtime.
• Zero-Trust-Access-native — the Worker is a natural place to validate the Access JWT and enforce per-endpoint policy.

Contrast

Unlike patterns/protocol-compatible-drop-in-proxy, the Middleware Worker isn't necessarily protocol-compatible on both sides: it translates between the application's expected shape (e.g. local CDP, ANTHROPIC_BASE_URL, local filesystem) and the platform's shape (HTTP APIs, object-storage mounts, Zero Trust policies). Unlike patterns/caching-proxy-tier, it's not primarily about caching — it's about owning cross-boundary concerns at a single policy enforcement point.

Seen in

• sources/2026-01-29-cloudflare-moltworker-self-hosted-ai-agent — canonical wiki instance. Moltworker is architecturally a Hono-style entrypoint Worker that proxies: (1) Moltbot's LLM calls to AI Gateway, (2) Moltbot's CDP frames to Browser Rendering, (3) Moltbot's filesystem writes to R2 via Sandbox SDK mount, and (4) every inbound request through Zero Trust Access. Moltbot's own code is unchanged.
• sources/2026-04-20-cloudflare-internal-ai-engineering-stack — the same pattern at enterprise scale. Every LLM request from internal tooling flows through a Hono Worker that validates Access JWT, strips client auth, injects real provider keys, and tags requests with anonymous per-user UUIDs before forwarding to AI Gateway.

Related

• systems/cloudflare-workers — the runtime the adapter lives in.
• systems/cloudflare-zero-trust-access — the common front-door identity primitive.
• patterns/protocol-compatible-drop-in-proxy — adjacent; that pattern is protocol-preserving; this one is protocol-translating.
• patterns/caching-proxy-tier — adjacent; that pattern is cache-centric; this one is concern-ownership-centric.
• companies/cloudflare — the architectural vocabulary's origin.