Edge functions, plainly explained

Edge functions are small pieces of code that run on a server geographically close to whoever called them. That is the whole pitch. Everything else — the runtime quirks, the cold-start arithmetic, the missing Node modules — is consequence.

The mental model

Picture a regular Node server in one city. Now imagine the same code, deployed simultaneously to three hundred cities, and the request automatically lands in the closest one. That's an edge function. Latency drops. Throughput scales horizontally without you doing anything. The tradeoff is that the runtime is not really Node — it's a stripped-down JavaScript runtime built around web standards.

What runs

• Anything that uses fetch, Request, Response, Headers, URL, crypto.subtle, TextEncoder.
• Most pure-JavaScript npm packages.
• Database queries over HTTP — Hyperdrive, Neon, PlanetScale, Supabase REST.

What doesn't

• child_process — there is no shell to spawn into.
• Native modules — sharp, canvas, anything with a binding.gyp.
• Long-running TCP connections — Postgres wire protocol, Redis pub/sub.
• fs.watch — the filesystem isn't really a filesystem.

A working example

Here's a server function that runs at the edge, fetches from a third-party API, and returns JSON. Notice there's nothing special about the code itself — that's the point.

ts
import { createServerFn } from '@tanstack/react-start';

export const getWeather = createServerFn({ method: 'GET' })
  .inputValidator((input: { city: string }) => input)
  .handler(async ({ data }) => {
    const res = await fetch(
      `https://api.weather.example/v1/current?city=${encodeURIComponent(data.city)}`,
      { headers: { Authorization: `Bearer ${process.env.WEATHER_KEY}` } }
    );
    if (!res.ok) throw new Error('Upstream failed');
    return await res.json();
  });

Cold starts, briefly

Edge functions cold-start in single-digit milliseconds because there is no Node process to boot — just an isolate to allocate. That's why edge feels fast even on the first request. It is also why most caching strategies you'd reach for on a traditional server don't matter as much: the function itself is the cache.

When not to use the edge

If your workload is a long-running websocket, a video transcoder, or a queue worker grinding through millions of jobs — edge isn't the shape you want. Use a regular server. Edge is for the request-response loop, where every millisecond between intent and pixel matters.

For everything else — APIs, auth, server-rendered pages, webhooks, AI streaming — the edge is the new default. It just took us a while to build the runtime to match.