AI Rules for Edge Computing

AI Deploys to One Data Center

AI generates applications deployed to: a single region (us-east-1 for everyone, 200ms latency for users in Tokyo), Node.js-only runtime (full Node.js APIs that cannot run at the edge), no edge middleware (auth checks and redirects require a round-trip to the origin), no edge caching (every request hits the origin server), and no data locality awareness (database in Virginia, user in Sydney, 300ms per query). The infrastructure ignores that the internet is global.

Modern edge computing is: globally distributed (code runs at 300+ edge locations worldwide), runtime-aware (edge-compatible code using Web APIs, not Node.js-specific APIs), middleware-optimized (auth, redirects, and A/B testing at the edge — no origin round-trip), cache-strategic (stale-while-revalidate for dynamic content at the edge), and data-local (database replicas or edge caches near users). AI generates none of these.

These rules cover: edge-compatible code patterns, edge middleware for auth and routing, data locality strategies, edge caching with stale-while-revalidate, and edge runtime constraints.

Rule 1: Edge-Compatible Code Patterns

The rule: 'Write code that runs in the edge runtime: Web Standard APIs only (fetch, Request, Response, URL, TextEncoder, crypto.subtle). No Node.js-specific APIs: no fs, no path, no child_process, no Buffer (use Uint8Array), no process.env access patterns that depend on Node.js. The edge runtime is V8-based (like a browser), not Node.js. Code that works in a Cloudflare Worker works at the edge everywhere.'

For runtime selection in Next.js: 'export const runtime = "edge" in route handlers and middleware to opt into the edge runtime. Default is "nodejs" (full Node.js, single region). Edge runtime: globally distributed, sub-millisecond cold starts, but limited APIs. Use edge for: middleware, simple API routes, redirects, auth checks, and response transformations. Use Node.js for: database connections requiring TCP, heavy computation, and Node.js-specific libraries.'

AI generates: code using fs.readFileSync, Buffer.from, and process.cwd() — all Node.js-only APIs that fail at the edge. Replacing Buffer.from with new TextEncoder().encode, and fs with fetch from a KV store or R2 bucket: same functionality, edge-compatible. The Web Standards API surface covers most use cases — Node.js specifics are rarely necessary.

Web Standard APIs: fetch, Request, Response, URL, crypto.subtle, TextEncoder
No Node.js APIs at edge: no fs, path, Buffer, child_process, process.cwd()
Uint8Array instead of Buffer — TextEncoder/TextDecoder for string encoding
Next.js: export const runtime = 'edge' for edge routes and middleware
Edge for: middleware, auth, redirects. Node.js for: TCP databases, heavy compute

Rule 2: Middleware at the Edge

The rule: 'Run authentication checks, redirects, geo-routing, A/B tests, and feature flags at the edge — not at the origin. Edge middleware runs before the request reaches your server, at the edge location nearest to the user. Auth check at the edge: verify the JWT, redirect unauthenticated users to login — no round-trip to the origin. The unauthorized user is redirected in 10ms (edge) instead of 200ms (origin).'

For Next.js middleware: 'middleware.ts at the project root runs on every request (filter with matcher config). Use for: authentication guards (check session cookie, redirect to /login), locale detection (Accept-Language header, redirect to /en or /fr), feature flags (read flag from cookie or edge config, rewrite to variant), and bot detection (block scrapers before they hit your server). Each middleware function adds 1-5ms of latency — negligible compared to origin round-trips.'

AI generates: auth checks in getServerSideProps or API route middleware — at the origin. An unauthenticated user in Tokyo makes a round-trip to us-east-1 (200ms) just to be told to go to the login page. Edge middleware: the check happens in Tokyo (10ms), the redirect happens in Tokyo. The origin server never sees the request. 20x faster for the common case.

💡 10ms vs 200ms Auth Check

Auth check at the origin: unauthenticated user in Tokyo round-trips to us-east-1 (200ms) just to be redirected to /login. Edge middleware: the check happens in Tokyo (10ms), the redirect happens in Tokyo. The origin never sees the request. 20x faster for the common case.

Rule 3: Data Locality Strategies

The rule: 'Place data near users: (1) Edge KV stores (Cloudflare KV, Vercel Edge Config) for configuration, feature flags, and read-heavy key-value data. (2) Regional database replicas (PlanetScale, Neon, CockroachDB) for read queries near users. (3) Edge caching (CDN cache with stale-while-revalidate) for API responses. (4) Write to primary, read from nearest replica — accept eventual consistency for reads, strong consistency for writes.'

For the read/write split: 'Most web applications are 90%+ reads. Place read replicas globally; keep the write primary in one region. A user in Sydney reads from the Sydney replica (20ms) but writes go to the US primary (200ms). The write is infrequent (form submission, purchase) and the user expects a loading state. The reads are constant (page views, API calls) and must be fast. Optimize the 90% case.'

AI generates: one database in us-east-1, every query from every user crosses the globe. A page with 5 database queries: 5 x 200ms = 1 second of latency for a Tokyo user. With a regional replica: 5 x 20ms = 100ms. Same queries, 10x faster, because the data is nearby. Neon serverless supports read replicas; PlanetScale has automatic global replication.

Edge KV for config and flags — globally replicated, sub-millisecond reads
Regional database replicas for read queries — 20ms instead of 200ms
Write to primary region, read from nearest replica — eventual consistency for reads
90%+ reads: optimize the common case with replicas, accept latency for rare writes
Neon, PlanetScale, CockroachDB — built-in global replication support

⚠️ 5 Queries x 200ms = 1 Second

One database in us-east-1, user in Tokyo. A page with 5 queries: 5 x 200ms = 1 second of pure latency. With a regional replica in Tokyo: 5 x 20ms = 100ms. Same queries, same data, 10x faster because the data is nearby.

Rule 4: Edge Caching with Stale-While-Revalidate

The rule: 'Cache dynamic API responses at the edge with stale-while-revalidate: Cache-Control: public, s-maxage=60, stale-while-revalidate=300. s-maxage=60: the edge serves the cached response for 60 seconds. stale-while-revalidate=300: after 60 seconds, serve the stale response immediately while fetching a fresh one in the background. The user always gets an instant response; freshness is maintained asynchronously.'

For cache granularity: 'Cache key by: URL path (default), query parameters (pagination, filters), geographic region (different content per country), and user segment (logged-in vs anonymous — use Vary header). Do not cache: user-specific data (account pages, dashboards), real-time data (stock prices, chat), and mutation responses (POST, PUT, DELETE). Cache: product pages, article content, search results, and public API responses.'

AI generates: no caching headers on API responses. Every request hits the origin, every user waits for the database. With s-maxage=60 and stale-while-revalidate=300: the first user waits for the origin; the next 1000 users get an instant edge response. The origin handles 1 request per minute instead of 1000. Same freshness (60-second maximum staleness), 1000x less origin load.

ℹ️ 1 Origin Request, 1000 Edge Responses

s-maxage=60, stale-while-revalidate=300: the first user hits the origin. The next 1000 users in that minute get an instant edge-cached response. The origin handles 1 request per minute instead of 1000. Same freshness guarantee, 1000x less origin load.

Rule 5: Edge Runtime Constraints

The rule: 'Understand edge runtime limits: (1) Execution time: 30 seconds max on most platforms (Cloudflare Workers: 30s, Vercel Edge Functions: 30s). (2) Memory: 128MB typical limit. (3) No persistent connections: TCP sockets close between requests (use HTTP-based database drivers like @neondatabase/serverless, not pg with connection pooling). (4) No filesystem: use KV stores, R2/S3, or fetch for file access. (5) Cold start: sub-millisecond (V8 isolate), not seconds (container-based).'

For database connectivity: 'Traditional database drivers (pg, mysql2) use TCP connections — incompatible with edge runtimes that do not support persistent TCP. Solutions: HTTP-based drivers (@neondatabase/serverless uses HTTP/WebSocket), connection proxies (PlanetScale serverless driver, Supabase edge functions), and edge-native databases (Cloudflare D1, Turso/libSQL). The database driver choice determines whether your app can run at the edge.'

AI generates: import { Pool } from 'pg' — a TCP connection pool that fails at the edge. Replace with: import { neon } from '@neondatabase/serverless' — HTTP-based, edge-compatible, same SQL interface. The query syntax is identical; the transport layer is HTTP instead of TCP. One import change, edge-compatible database access.

Complete Edge Computing Rules Template

Consolidated rules for edge computing.

Web Standard APIs only at edge — no Node.js-specific fs, Buffer, child_process
Middleware at edge: auth, redirects, geo-routing, feature flags — 10ms not 200ms
Data locality: edge KV for config, regional replicas for reads, primary for writes
stale-while-revalidate caching: instant edge response, async background refresh
HTTP-based database drivers: @neondatabase/serverless, PlanetScale serverless
Edge limits: 30s execution, 128MB memory, no persistent TCP, no filesystem
Sub-millisecond cold starts (V8 isolates) — no container spin-up delay
Optimize for reads (90% of traffic) — replicas and caching at the edge