Running JavaScript at the edge: what it is, when it helps, what it costs

Edge compute has become a standard feature of large CDNs: Cloudflare Workers, Deno Deploy, Fastly, Vercel and others all let you run a small function at a point of presence near the visitor rather than at your origin. We get asked about it a lot, so here is a vendor-neutral explanation of what it is, where it earns its keep, and where it does not. Omega does not sell an edge-compute product, so nothing here is a pitch; it is just the lay of the land.

What it actually is

Most edge runtimes run on V8 Isolates, the same engine technology behind those products. Each request gets a lightweight isolate rather than a container or VM, so startup is fast and there is little per-request overhead. You typically get a Fetch-style API, basic crypto primitives, and sometimes a small key-value store for configuration. The model is: your function sits in front of the request, can inspect or rewrite it, and either answers directly or forwards to origin.

Where edge compute helps

• · URL rewrites and redirects, moved out of the application server
• · A/B variant selection before the HTML reaches the browser, avoiding client-side flicker
• · Lightweight auth checks, like validating a token before letting a request reach origin
• · Geolocation-based routing, serving a regional variant without an origin round trip
• · Header and response shaping, adding security headers or stripping sensitive fields
• · Simple bot filtering, blocking or challenging obvious patterns at the edge

// A typical shape: inspect, optionally short-circuit, else forward.
export default {
  async fetch(request) {
    const url = new URL(request.url);

    // Public paths pass straight through.
    if (url.pathname.startsWith('/public/')) {
      return fetch(request);
    }

    // Reject early instead of paying a round trip to origin.
    const auth = request.headers.get('Authorization');
    if (!auth?.startsWith('Bearer ')) {
      return new Response('Unauthorized', { status: 401 });
    }

    return fetch(request);
  },
};

Where it does not help

Edge runtimes are not general-purpose servers. CPU time per request is tightly capped, the key-value stores are eventually consistent and not databases, and you do not get persistent local disk or long-lived connections. Anything heavy, a real database, image processing, long computation, belongs at your origin or a proper backend. The edge is for small, latency-sensitive decisions on the request path, not for the bulk of your application logic.

The trade-offs to weigh

Running code at the edge means another deploy target, another place a bug can break every request, and lock-in to one provider's runtime quirks. The eventual-consistency window on edge key-value stores trips people up: a value you wrote may take seconds to reach every PoP. And debugging is harder when the code runs in dozens of locations instead of one. None of these are dealbreakers, but they are reasons not to reach for the edge by default.

The honest recommendation

If you have a specific, small job on the request path that benefits from running near the visitor, edge compute is a clean tool and worth learning. If you are reaching for it to run your application, you have picked the wrong layer. Most sites we host do not need it at all: good caching at the CDN and a fast origin cover the common cases. Use the edge where it is genuinely the right shape, and keep the rest of your logic where it belongs.

Edge compute is a scalpel, not a server. It is great for small decisions near the visitor and a poor place to run an application.