Every millisecond matters. When a user in Tokyo requests data from a server in Virginia, that request travels roughly 11,000 miles — through undersea cables, across routing hops, and back again. The round trip takes 150-200 milliseconds at the speed of light, and real-world latency is often worse. Edge computing eliminates this distance problem by running your code on servers distributed across the globe, as close to your users as physically possible.
What Edge Computing Actually Is
Edge computing runs your application logic on a network of servers positioned at the "edge" of the internet — in data centers spread across dozens or hundreds of cities worldwide. Instead of every request traveling to a single origin server, it is handled by the nearest edge node.
This is different from a traditional CDN, which only caches static files. A CDN serves your images, CSS, and JavaScript from nearby servers, but any dynamic logic — authentication, personalization, database queries — still goes back to the origin. Edge computing runs actual code at the edge, meaning you can execute business logic, transform data, and make decisions without the round trip.
Think of it this way: a CDN is a library with copies of popular books in every neighborhood. Edge computing is putting a librarian in every neighborhood who can answer questions, make recommendations, and check your library card — not just hand you a book.
The Major Edge Platforms
Cloudflare Workers
Cloudflare Workers run on over 300 locations worldwide. They use the V8 JavaScript engine (the same engine that powers Chrome) and start up in under 5 milliseconds — no cold starts like traditional serverless functions. Workers support JavaScript, TypeScript, Rust, C, and C++ via WebAssembly.
Key features include Workers KV for key-value storage at the edge, Durable Objects for stateful edge computing, and R2 for S3-compatible object storage without egress fees. The free tier includes 100,000 requests per day.
Vercel Edge Functions
Built on Cloudflare's network, Vercel Edge Functions integrate tightly with Next.js. Edge middleware runs before every request, enabling authentication checks, A/B testing, and geolocation-based routing without touching the origin server. Edge functions use the Web API standard (fetch, Request, Response), making them familiar to any web developer.
Deno Deploy
Deno Deploy runs TypeScript and JavaScript on a global network with zero-config deployments. It uses the Deno runtime, which includes built-in TypeScript support, Web API compatibility, and a security-first permissions model. Deploy from a GitHub repository and your code runs at the edge within seconds.
AWS CloudFront Functions and Lambda@Edge
AWS offers two edge compute options. CloudFront Functions are lightweight (sub-millisecond startup, up to 10KB code) and run on every CloudFront request — ideal for header manipulation, URL rewrites, and simple redirects. Lambda@Edge is heavier (up to 50MB, supports Node.js and Python) and runs at regional edge caches — better for complex logic like authentication or image transformation.
Practical Use Cases
Authentication at the Edge
Verifying a JWT token does not require a database query — it is a cryptographic operation that can run anywhere. By validating tokens at the edge, you reject unauthorized requests before they ever reach your origin server. This reduces origin load, improves response time for authenticated users, and blocks malicious traffic at the perimeter.
A typical implementation: edge middleware checks the Authorization header, verifies the JWT signature, and either passes the request through to the origin (with decoded user info in a header) or returns a 401 immediately.
A/B Testing Without Client-Side Flicker
Traditional A/B testing injects JavaScript on the client that swaps content after the page loads, causing a visible flicker. Edge-based A/B testing decides which variant to serve before the HTML reaches the browser. The user sees only their assigned variant — no flicker, no layout shift, no JavaScript overhead.
The edge function reads a cookie (or assigns one), selects the variant, and either rewrites the request to the correct origin path or modifies the response HTML directly. The test runs at network speed with zero impact on page performance.
Geolocation and Personalization
Every edge request includes the user's approximate location — country, region, city, and sometimes postal code. This enables instant personalization without a geolocation API call:
- Show prices in the local currency
- Display the nearest store location
- Route to a language-specific version of the site
- Block or allow access based on regional regulations
- Adjust shipping estimates based on proximity to fulfillment centers
Image Optimization
Transforming images at the edge — resizing, converting to WebP or AVIF, adjusting quality based on connection speed — eliminates the need to pre-generate every size and format combination. A single high-resolution source image is transformed on the fly at the edge node nearest to the user. Results are cached, so the transformation happens only once per unique combination.
API Rate Limiting and Bot Protection
Rate limiting at the edge stops abuse before it reaches your application servers. Edge functions can track request counts per IP address (using edge key-value stores), apply sliding window algorithms, and return 429 responses from the nearest edge node. Legitimate traffic passes through unaffected while bots and scrapers are throttled at the perimeter.
Edge vs Origin: When Each Makes Sense
Edge computing is not a replacement for origin servers. It is best for workloads that are latency-sensitive, stateless or lightly stateful, and benefit from geographic distribution.
| Best at the Edge | Best at the Origin |
|---|---|
| Authentication and authorization | Complex database transactions |
| A/B testing and feature flags | Data aggregation and reporting |
| Geolocation-based routing | Multi-table joins and queries |
| Request/response transformation | Background job processing |
| Rate limiting and bot detection | File uploads and processing |
| Redirects and URL rewrites | WebSocket connections (long-lived) |
| Image optimization | Machine learning inference (large models) |
The sweet spot for most web applications is a hybrid architecture: edge functions handle the fast, stateless work while the origin handles database-heavy operations. The edge can also cache origin responses, reducing how often the origin is hit at all.
Cost Comparison
Edge computing pricing varies by platform, but the general model is pay-per-request with generous free tiers:
- Cloudflare Workers: Free for 100K requests/day. Paid plan starts at $5/month for 10 million requests.
- Vercel Edge Functions: Included in all plans. Pro plan ($20/month) includes generous limits for most applications.
- Deno Deploy: Free for 1 million requests/month. Pro plan at $20/month.
- AWS Lambda@Edge: $0.60 per million requests plus $0.00005001 per GB-second of compute. No free tier for Lambda@Edge specifically.
For most web applications, edge computing costs less than traditional serverless because edge functions are smaller, start faster, and run for shorter durations. The savings compound when you factor in reduced origin server load — fewer requests reaching your origin means smaller (and cheaper) origin infrastructure.
Getting Started
The easiest entry point depends on your current stack:
- Next.js users: Add a
middleware.tsfile to your project root. It runs on Vercel's edge network automatically. Start with a simple redirect or authentication check. - Any framework: Create a Cloudflare Worker. The Wrangler CLI scaffolds a project in seconds. Deploy with
wrangler deployand your code runs globally in under a minute. - Deno users: Push a TypeScript file to a GitHub repo connected to Deno Deploy. Every push deploys to the edge automatically.
Start small. Pick one edge use case — geolocation redirects, authentication, or A/B testing — and implement it. Measure the latency improvement. Then expand from there.
Frequently Asked Questions
Can edge functions access my database?
Yes, but with caveats. Edge functions can make HTTP requests to your database API or connection pooler (like Supabase, PlanetScale, or Neon, which all offer HTTP-based database access). Direct TCP connections to databases are supported on some platforms (Cloudflare Workers with Hyperdrive, Vercel with connection pooling) but add latency if the database is far from the edge node. For best results, keep database-heavy logic on the origin and use the edge for caching and lightweight operations.
What are the limitations of edge computing?
Edge functions typically have execution time limits (50ms on Cloudflare free tier, 30 seconds on Vercel), memory limits (128MB is common), and restricted APIs (no filesystem access, limited Node.js compatibility). They are designed for fast, lightweight operations — not long-running computations or heavy data processing.
Is edge computing the same as serverless?
Edge computing is a subset of serverless. Both abstract away infrastructure management, but traditional serverless (AWS Lambda, Google Cloud Functions) runs in one or a few regions. Edge serverless runs in dozens or hundreds of locations simultaneously. The key difference is geographic distribution and the resulting latency reduction.
Related Reading
- AWS vs Azure vs GCP: Cloud Platform Comparison
- CI/CD Pipeline Guide: Automate Your Deployments
- Cloud Cost Optimization Strategies
Ready to move your app to the edge?
We architect and deploy edge-first web applications that load faster, scale globally, and cost less to run. Whether you are optimizing an existing app or building from scratch, we can help you leverage edge computing effectively.
Let's Talk Performance