Edge Computing for Full Stack Developers: A Practical Guide

Edge computing, in the context of web development, means running your server-side code on distributed nodes that are geographically close to the user making the request. Instead of a request traveling from Tokyo to a server in Virginia, it is handled by a node in Tokyo. This eliminates the round-trip latency for dynamic content, bringing response times from hundreds of milliseconds down to single-digit milliseconds for compute and adding only the latency to your data source. For full-stack developers, edge computing is now accessible through platforms like Vercel Edge Runtime and Cloudflare Workers without managing infrastructure.

TL;DR

Edge functions run your server-side logic on a global network of nodes close to users, dramatically reducing latency for dynamic responses. They use a lightweight runtime based on Web APIs (not full Node.js), which means some trade-offs in available APIs and execution limits. Use edge for latency-sensitive operations like auth checks, redirects, personalization, and API responses. Keep heavy compute and complex database operations in traditional serverless functions.

Why This Matters

The web performance community has spent years optimizing static asset delivery through CDNs. Your images, CSS, JavaScript, and pre-rendered HTML already serve from edge nodes worldwide. But dynamic content — API responses, personalized pages, authentication checks — has traditionally required a round trip to a centralized server.

For a user in Singapore accessing an application with servers in US-East, every dynamic request adds roughly 200-300ms of network latency before the server even starts processing. This latency is physics — the speed of light through fiber optic cables. No amount of server optimization can eliminate it.

Edge computing solves this by moving the compute to the user. When your authentication middleware, API route, or server-rendered page runs on an edge node in Singapore, that network latency disappears. The response is generated locally and returned in milliseconds.

This matters for real applications: faster authentication flows, instant personalization, reduced time-to-first-byte for dynamic pages, and the ability to perform logic like A/B testing, geolocation-based routing, and rate limiting without the latency penalty of a centralized server.

How It Works

Edge Runtime vs Node.js Runtime

The critical distinction for developers is that edge runtimes are not Node.js. They are based on the Web API standard (similar to what runs in browsers and service workers), which means a different set of available APIs.

Available in edge runtimes:

• ›fetch, Request, Response
• ›URL, URLSearchParams
• ›TextEncoder, TextDecoder
• ›crypto.subtle (Web Crypto API)
• ›setTimeout, setInterval
• ›ReadableStream, WritableStream
• ›Headers, FormData
• ›structuredClone

Not available in edge runtimes:

• ›fs (file system)
• ›child_process
• ›net, dgram (raw TCP/UDP sockets)
• ›Most native Node.js modules
• ›npm packages that depend on native modules

This constraint is what enables the performance advantage. Edge runtimes start in microseconds rather than the milliseconds required for a full Node.js cold start. The trade-off is a more limited API surface.

Edge Functions on Vercel

Vercel's Edge Runtime integrates directly with Next.js. You can run middleware, API routes, and even page rendering at the edge:

// middleware.ts — runs at the edge on every request
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
 
export function middleware(request: NextRequest) {
  // Geolocation-based routing
  const country = request.geo?.country || "US";
 
  // Redirect users to country-specific content
  if (country === "DE" && !request.nextUrl.pathname.startsWith("/de")) {
    return NextResponse.redirect(new URL(`/de${request.nextUrl.pathname}`, request.url));
  }
 
  // A/B testing with cookies
  const bucket = request.cookies.get("ab-bucket")?.value;
  if (!bucket) {
    const newBucket = Math.random() < 0.5 ? "control" : "variant";
    const response = NextResponse.next();
    response.cookies.set("ab-bucket", newBucket, { maxAge: 60 * 60 * 24 * 30 });
    return response;
  }
 
  return NextResponse.next();
}
 
export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

// app/api/hello/route.ts — edge API route
export const runtime = "edge";
 
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const name = searchParams.get("name") || "World";
 
  return new Response(
    JSON.stringify({ message: `Hello, ${name}!`, timestamp: Date.now() }),
    {
      headers: { "Content-Type": "application/json" },
    }
  );
}

Cloudflare Workers

Cloudflare Workers provide a similar edge runtime with their own ecosystem of tools:

// src/index.ts — Cloudflare Worker
export interface Env {
  MY_KV: KVNamespace;
  DB: D1Database;
}
 
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
 
    if (url.pathname === "/api/config") {
      // Read from KV store (globally replicated key-value)
      const config = await env.MY_KV.get("app-config", "json");
      return Response.json(config);
    }
 
    if (url.pathname === "/api/products") {
      // Query D1 database (distributed SQLite)
      const { results } = await env.DB.prepare(
        "SELECT id, name, price FROM products WHERE active = 1 LIMIT 20"
      ).all();
      return Response.json(results);
    }
 
    return new Response("Not Found", { status: 404 });
  },
};

Edge-Compatible Databases

Traditional databases expect persistent TCP connections from a centralized server. Edge functions are distributed and short-lived, making traditional connections impractical. Several solutions have emerged:

HTTP-based database drivers allow edge functions to query databases over HTTP instead of TCP:

// Using Neon's serverless driver (HTTP-based Postgres)
import { neon } from "@neondatabase/serverless";
 
export const runtime = "edge";
 
export async function GET() {
  const sql = neon(process.env.DATABASE_URL!);
  const posts = await sql`SELECT id, title, published_at FROM posts ORDER BY published_at DESC LIMIT 10`;
  return Response.json(posts);
}

// Using Turso (distributed SQLite at the edge)
import { createClient } from "@libsql/client/web";
 
export const runtime = "edge";
 
export async function GET() {
  const client = createClient({
    url: process.env.TURSO_URL!,
    authToken: process.env.TURSO_AUTH_TOKEN!,
  });
 
  const result = await client.execute("SELECT * FROM users WHERE active = 1");
  return Response.json(result.rows);
}

Globally distributed data stores like Upstash Redis are purpose-built for edge:

// Using Upstash Redis for rate limiting at the edge
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
 
const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "10 s"), // 10 requests per 10 seconds
});
 
export const runtime = "edge";
 
export async function POST(request: Request) {
  const ip = request.headers.get("x-forwarded-for") || "anonymous";
  const { success, limit, remaining } = await ratelimit.limit(ip);
 
  if (!success) {
    return new Response("Rate limit exceeded", {
      status: 429,
      headers: {
        "X-RateLimit-Limit": limit.toString(),
        "X-RateLimit-Remaining": remaining.toString(),
      },
    });
  }
 
  // Process the request...
  return new Response("OK");
}

Practical Implementation

Latency Reduction Patterns

The most impactful edge computing patterns focus on operations that are both latency-sensitive and lightweight:

Authentication and session validation. Validate JWTs or session tokens at the edge before the request even reaches your origin server. Invalid requests are rejected immediately without consuming origin resources.

Feature flags and A/B testing. Evaluate feature flags at the edge to serve the correct variant without a round trip to a flag service. Store assignments in cookies for consistency.

Geolocation-based personalization. Currency conversion, language selection, and regional content can be determined at the edge using the request's geographic information.

API response caching with stale-while-revalidate. Serve cached API responses from the edge while asynchronously refreshing the cache from the origin:

export const runtime = "edge";
 
export async function GET(request: Request) {
  const cacheKey = new URL(request.url).pathname;
 
  // Check edge cache
  const cache = caches.default;
  const cachedResponse = await cache.match(request);
 
  if (cachedResponse) {
    // Return cached response, revalidate in background
    const age = cachedResponse.headers.get("age");
    if (age && parseInt(age) > 60) {
      // Cache is stale, revalidate in background
      // (the current request still gets the cached response)
      fetchAndCache(request, cache);
    }
    return cachedResponse;
  }
 
  return fetchAndCache(request, cache);
}
 
async function fetchAndCache(request: Request, cache: Cache) {
  const response = await fetch(process.env.ORIGIN_URL + new URL(request.url).pathname);
  const responseToCache = new Response(response.body, {
    headers: {
      ...Object.fromEntries(response.headers),
      "Cache-Control": "public, s-maxage=300",
    },
  });
  await cache.put(request, responseToCache.clone());
  return responseToCache;
}

Common Pitfalls

Assuming edge is always faster. If your edge function needs to fetch data from a database in US-East, a user in Japan will experience: Japan to edge (fast) + edge to US-East database (slow) + US-East to edge (slow) + edge to Japan (fast). The total latency may be worse than a serverless function colocated with the database. Edge works best when data is also distributed or cached.

Exceeding execution limits. Edge functions typically have strict CPU time limits (often 30ms-50ms on the free tier, up to a few seconds on paid plans). Long-running computations will be terminated. Keep edge functions lightweight.

Using incompatible npm packages. Many popular npm packages depend on Node.js-specific APIs. Always verify that your dependencies work in the edge runtime before deploying. Check for fs, path, crypto (the Node.js module, not Web Crypto), and native bindings.

Not considering cold starts. While edge cold starts are faster than Node.js serverless cold starts, they still exist. For infrequently accessed routes, the first request may still have added latency.

Ignoring data locality. Distributing compute without distributing data creates a new bottleneck. If all your data lives in one region, running code at the edge adds a network hop rather than removing one.

When to Use (and When Not To)

Use edge computing for:

• ›Authentication and authorization middleware
• ›Redirects and URL rewrites
• ›A/B testing and feature flag evaluation
• ›Rate limiting and bot protection
• ›Geolocation-based personalization
• ›Lightweight API responses that can be cached or computed quickly
• ›Image and content transformation at the CDN layer

Do not use edge computing for:

• ›Long-running computations (video processing, large data transformations)
• ›Workloads that require full Node.js APIs
• ›Operations tightly coupled to a single-region database without edge-compatible drivers
• ›Tasks where the latency difference is not perceptible to users
• ›Applications where cold starts at the edge are comparable to centralized serverless

Consider a hybrid approach: Use edge for the latency-sensitive entry points (middleware, auth, routing) and serverless for the heavy backend work (complex queries, data processing, integrations).

FAQ

What is the difference between edge functions and serverless functions?

Serverless functions run in one or a few centralized regions and use Node.js with full API access. Edge functions run on a globally distributed network close to users, use a lighter runtime based on Web APIs, and have restrictions on execution time, memory, and available APIs.

Can I use a database with edge functions?

Yes, but you need an edge-compatible database or connection strategy. Options include Turso (distributed SQLite), PlanetScale with their serverless driver, Neon with their HTTP driver, Upstash Redis, and Cloudflare D1. Traditional database connections using TCP are not available in all edge runtimes.

When should I NOT use edge computing?

Avoid edge computing for long-running tasks, CPU-intensive operations, workloads that need full Node.js APIs (like fs or child_process), applications tightly coupled to a single database region, and cases where cold start differences between edge and serverless are negligible for your use case.

Does edge computing replace serverless?

No. Edge and serverless are complementary. Use edge for latency-sensitive operations like authentication, redirects, A/B testing, and personalization. Use serverless for heavier compute tasks, complex database operations, and workloads that need full Node.js capabilities.