Edge functions run your code in locations near your users for lower delay. Learn what they are good at, what they cannot do well, and how to split work with your main servers.

When someone in Mumbai opens a site whose server sits in another continent, every request has to travel a long way and back. Light is fast, but not that fast. The delay adds up, especially for pages that need several round trips.

Edge computing reduces that delay by running small pieces of your code in many locations around the world, close to users.

Edge and origin

Your main application servers and database are called the origin. They usually live in one or a few regions. The edge is a network of many smaller locations run by a CDN or platform. Code running there can answer a request without ever contacting the origin.

The edge handles what it can and forwards the rest.

What the edge is good at

  • Redirects and rewrites. Send users to the right page or language version.
  • Authentication checks. Reject requests with a missing or invalid token before they reach your servers.
  • Caching and personalization. Serve a cached page, with small per-user touches.
  • A/B testing and feature flags. Decide which variant to show.
  • Security filters. Block bots and bad traffic early.

What it is not good at

  • Heavy data work. Your database is in one place. If an edge function must call it many times, the saved distance is lost.
  • Long running jobs. Edge functions usually have tight limits on CPU time and memory.
  • Anything needing the full set of server libraries. Edge runtimes often support only a subset of what a normal server offers.
  • Strongly consistent data. Spreading data worldwide means copies may be briefly out of date.
Quick, light, stateless work goes to the edge. Heavy and data-centred work stays at the origin.

A simple example

edge-function.js
// Runs near the user. Rejects bad requests before they reach the origin.
export default async function handler(request) {
  const token = request.headers.get("authorization");

  if (!token) {
    return new Response("Sign in required", { status: 401 });
  }

  // Looks fine, pass it on to the origin
  return fetch(request);
}

The syntax differs between platforms, but the pattern is the same: inspect the request, decide quickly, and either answer or pass it along.

How to decide

  1. Measure first. Find out where users actually lose time. If the slowness is a database query, the edge will not fix it.
  2. Move small, stateless work first. Checks, redirects and caching are low risk.
  3. Keep data decisions in mind. If your database is in one region, avoid chatty edge code that calls it repeatedly.
  4. Test limits early. Check the platform’s limits on time, memory and supported libraries before you commit.