Edge computing moves computation physically closer to the end user — geographically distributed points of presence, rather than one centralized datacenter — genuinely reducing latency for the workloads that benefit from it.
// A Cloudflare Worker running at the edge, close to the requesting user,
// rather than round-tripping to a single origin server potentially far away
export default {
async fetch(request) {
const country = request.cf.country;
if (country === 'DE') {
return Response.redirect('https://example.de');
}
return fetch(request); // pass through to origin otherwise
}
}
What Genuinely Benefits from Running at the Edge
- Simple request routing, redirects, and A/B test bucketing — logic that doesn’t need a database round-trip
- Static/cached content serving, benefiting directly from physical proximity to the user
- Basic authentication checks and request validation before hitting the origin at all
The Real Constraints
Edge runtimes are deliberately limited — no persistent local disk, restricted execution time, and often a genuinely different (more constrained) JavaScript/WASM runtime than a full Node.js server, not full Node.js compatibility. Anything requiring heavy computation, a large dependency tree, or direct database access with complex transactions generally still belongs at the origin, not the edge.