“Edge computing” went from buzzword to mainstream production by 2025. By 2026 every senior frontend engineer is expected to understand at least the concept. Cloudflare Workers, Vercel Edge Runtime, Deno Deploy, Bun, and Netlify Edge Functions are mature platforms with real adoption. This guide covers what frontend engineers actually need to know for interviews and production.
What “edge” means
Compute that runs at points-of-presence near the user, not in a single origin region. Latency from user to “edge” is typically 30–80 ms vs 100–300 ms to a single origin. Cold starts are sub-millisecond on Cloudflare Workers (V8 isolates), 50–200 ms on Vercel/Deno (V8 isolates with more overhead), longer on container-based edge (Lambda@Edge, AWS App Runner).
The major platforms
Cloudflare Workers
- V8 isolates, sub-ms cold starts
- Largest network (300+ cities)
- KV store, R2 (object storage), D1 (SQLite at edge), Durable Objects (stateful), Queues
- Heavy use of Web APIs (Fetch, Streams), not Node.js
- Free tier generous
Vercel Edge Runtime
- Built on Cloudflare Workers under the hood
- Tight integration with Next.js
- Edge Functions, Edge Middleware, Edge Config (small-data store)
- Vercel-managed; less primitive control than Cloudflare directly
Deno Deploy
- V8 isolates, fast cold start
- Native TypeScript
- Web standards (Fetch, KV, ImportMap)
- Smaller network than Cloudflare but rapidly growing
Bun + Bun Cloud
- Newer; primarily a runtime + bundler that runs at edge via various platforms
- Compatible with Node.js APIs (broader ecosystem)
- Performance-focused; sub-ms cold starts
Lambda@Edge / CloudFront Functions
- AWS’s edge offerings
- CloudFront Functions are sub-ms but very limited (no async, tiny memory)
- Lambda@Edge is fuller but slower (cold starts hundreds of ms)
- Best for pure CDN-augmentation scenarios
What edge is good for
- A/B testing and feature flags at the edge — reads a header, rewrites response
- Authentication and authorization gates — verify JWT, route accordingly
- Personalization that does not need user-specific data lookups
- Rendering personalized HTML close to the user (Next.js edge rendering)
- Image transformations on the fly
- Cache key manipulation
- Geographic routing
What edge is NOT good for
- Heavy compute (V8 isolates have CPU limits)
- Large dependency graphs (cold start grows with bundle size)
- Long-running workloads (typical 30s timeout)
- Workloads needing the full Node.js API surface (some edge runtimes lack
fs,net, etc.) - Direct database connections to far-away DBs (latency to DB defeats edge benefit; use edge KV or read replicas)
The latency story
Edge wins when:
- The work is small and the data is local (KV at edge, immutable logic)
- The user is far from origin
Edge loses when:
- The work needs to call origin anyway (you pay user→edge + edge→origin)
- The bundle is large (cold start dominates)
Common interview questions
- “When would you use Cloudflare Workers vs a regional Lambda?”
- “What are the limits of edge computing?”
- “How do you handle a database that lives in a single region from an edge function?”
- “Walk me through how you would A/B test at the edge.”
- “What is the difference between Vercel Edge Runtime and Vercel Serverless Functions?”
Edge data stores
- Cloudflare KV: eventually-consistent global key-value, sub-ms reads at edge
- Cloudflare D1: SQLite with read replicas at the edge
- Durable Objects: single-region stateful objects with consistency
- Vercel Edge Config: small JSON, replicated globally
- Upstash Redis: edge-friendly Redis with global replication
- PlanetScale (MySQL) and Neon (Postgres) with edge-friendly drivers
The streaming-rendering pattern
Edge rendering shines when combined with streaming. Render the shell at the edge near the user; stream the rest as data arrives:
- HTML start streams immediately (low TTFB)
- Edge function calls origin/services in parallel
- As data arrives, render and stream additional HTML
- User sees content fast even if some sections take longer
Next.js App Router, Remix, and SvelteKit all support this pattern.
Limits to call out in interviews
- CPU time per request: typically 10–50 ms compute time on free tiers, 50–500 ms on paid
- Memory: 128 MB typical
- Bundle size: 1–10 MB depending on platform
- Subrequest fan-out: typically capped at 50
- Long-lived connections: not supported on most isolate-based runtimes
What separates senior from staff
Senior: knows what edge is and a major platform. Staff: discusses the latency model honestly (when edge does and does not win), handles the database-distance problem, and articulates the streaming + edge rendering pattern.
Frequently Asked Questions
Should I deploy my whole app to the edge?
Usually no. Most apps are a hybrid: static assets and lightweight functions at edge; data-heavy workloads in regional compute. The current best practice is “edge for the entry; origin for the data.”
How do edge isolates differ from containers?
Isolates share the runtime process; containers are full processes with their own memory. Isolates start in microseconds; containers in seconds. Isolates have less surface area (no fs, no native modules); containers can run anything.
Is Edge Functions a long-term bet?
Yes. The pattern of compute-near-user is durable. Specific platforms will rise and fall, but the abstraction is here to stay.