Workers

Workers run JavaScript or TypeScript on Cloudflare's edge using the V8 isolate model — not full Node.js. Handlers receive `fetch` events, can route, rewrite, authenticate, or call bindings (KV, R2, D1, Durable Objects) with low latency worldwide.

					export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    if (url.pathname.startsWith('/api/')) {
      return fetch(`https://origin.example${url.pathname}`, request);
    }
    return env.ASSETS.fetch(request);
  },
};
				

| Constraint | Implication | |------------|-------------| | No native Node APIs | Use Workers-compatible libs or polyfills | | CPU/time limits | Offload heavy work to origin or queues | | Bindings | Typed access to KV, R2, D1, DO |

Wrangler deploys with environments, secrets, and routes. Good fits: auth at edge, A/B routing, lightweight BFF, geo headers, JWT verification before origin.

On interviews: Workers vs Lambda vs Node server, runtime limits, bindings architecture, secret handling, and when edge logic should stay thin.

Common pitfalls: porting Express apps verbatim; long CPU or large JSON transforms at edge; assuming `fs` or native modules work; stateful sessions without Durable Objects or external store.

The trade-off is global low latency and origin offload versus runtime constraints, vendor APIs, and debugging distributed edge code.

Checklist:

• Keep handlers small and I/O-bound.
• Use bindings instead of hard-coded origin secrets.
• Test with Wrangler locally and staged routes.
• Fall back to origin for heavy or Node-specific work.