Static and Edge
Static and edge deployment is the split between prebuilt, cacheable output and small request-time code that runs near the user. Static files need no per-request compute; edge code can inspect the incoming request, but should not depend on fresh private data, heavyweight server libraries, or secrets that require an origin runtime.
The problem is that “close to the user” is not the same as “has access to your application state”. CDNs and edge runtimes are excellent at reducing round trips for shared content and simple routing decisions. They become dangerous when asked to serve user-specific HTML, read private database rows, or perform authorisation that depends on fresh state. The result can be leaked cached pages, stale decisions, or slower requests that bounce from the edge back to a distant database.
Static output is built ahead of time and served as bytes from cache: a pricing page, documentation page, image, script, or prerendered route whose response is identical for many users. Edge code is still per-request code, but it runs in a constrained runtime near the requester. It can look at headers, cookies, URL paths, language preferences, coarse location, and cached configuration, then rewrite, redirect, choose a cache key, block a bot, or forward to origin.
The trade-off is capability. Static content gives maximum cacheability but cannot safely vary by authenticated user unless the cache key and invalidation model are exact. Edge functions reduce network distance for lightweight decisions, but often lack the full server environment, native modules, filesystem access, long-running work, and normal database connectivity. Calling a central database from every edge location can remove the latency benefit and make reliability depend on cross-region links.
Engineers meet this boundary in frameworks and platforms that label routes as static, edge, serverless, or origin/server. Middleware, CDN functions, and workers are good fits for redirects, locale selection, header normalisation, simple experiments, and cache control. Route handlers, server actions, or traditional server processes are the right place for account pages, invoices, writes, permissions, and anything where the response depends on current private data.
Common questions
- What belongs at the edge?
- Put small, request-local decisions at the edge: redirects, rewrites, language or country selection, cache-key changes, bot filtering, and simple header logic. A good test is whether the decision can be made from the request, public configuration, or safely cached data. If it needs fresh per-user application state, it probably belongs at the origin.
- Why not put database queries in edge functions?
- Sometimes you can, but it depends on the database, driver, region layout, and runtime support. The common failure is an edge function in many locations calling one primary database far away, adding long network hops to every request. Native Node.js database drivers or ORMs may also fail because many edge runtimes are not full Node.js environments.
- Is static generation safe for personalised pages?
- Only if the generated output is not actually personalised, or if the caching model isolates every variant correctly. Publicly caching HTML that contains an email address, balance, or private list can serve one user’s page to another. Personalisation based on authenticated data should be rendered or fetched through an origin path with current authorisation checks.
- Is geolocation the same as identity?
- No. Edge geolocation is useful for defaults such as currency, language, regional routing, or compliance prompts. It does not prove who the user is and should not grant access to account data. Treat it as a hint about the request’s network location, not as authentication, authorisation, or a substitute for user-specific checks.