Edge Computing Vocabulary: Edge Functions, CDN, and Serverless at the Edge

Edge computing moves compute closer to users — reducing latency, improving reliability, and enabling personalisation without round-trips to a centralised origin server. As platforms like Cloudflare Workers, Vercel Edge Functions, and Fastly Compute@Edge become mainstream, the vocabulary of edge computing is increasingly essential for frontend and backend engineers alike.

Infrastructure Fundamentals

Edge node — A server in a distributed network located physically close to end users, typically in an internet exchange point or data centre near a major city. Edge nodes run edge functions and serve cached content. Phrase: “Requests from users in Tokyo are served by the edge node in Tokyo — not routed to our origin server in Virginia.”

PoP (Point of Presence) (pronunciation: each letter: P-O-P) — A physical location where edge infrastructure is deployed. A CDN with 300 PoPs has servers in 300 locations worldwide. Phrase: “Cloudflare’s network has over 300 PoPs — the average user is within 50 milliseconds of an edge node.”

Origin server — The central server that holds the authoritative version of your application and data. Edge infrastructure caches content from or proxies requests to the origin. Phrase: “Cache hit rate is 85% — only 15% of requests reach the origin server.”

Latency reduction at edge — The key benefit of edge computing: by running code or serving cached content geographically close to the user, round-trip time drops from hundreds of milliseconds to single digits. Phrase: “Moving authentication to the edge reduced Time to First Byte by 200ms for European users.”

Edge Runtimes and Functions

Edge runtime — A JavaScript (or WASM) execution environment optimised for edge nodes: minimal cold start, constrained APIs, and a subset of Node.js capabilities. Phrase: “The edge runtime doesn’t support Node.js fs — use the Fetch API and KV storage instead.”

V8 isolates — Lightweight JavaScript execution contexts used by Cloudflare Workers and similar platforms. Each request runs in an isolate rather than a full process or container. Isolates start in microseconds, eliminating traditional cold starts. Phrase: “Cloudflare Workers use V8 isolates — there’s no cold start because the isolate is already initialised.”

Cold start — The latency penalty when a serverless function must be initialised from scratch before handling a request. Traditional Lambda cold starts can be hundreds of milliseconds. Edge runtimes using V8 isolates largely eliminate this problem. Phrase: “Cold starts are a real concern for Lambda@Edge — consider Cloudflare Workers if your use case needs consistent sub-millisecond startup.”

Warm start — When a serverless function instance is already running and reused for a subsequent request, avoiding the cold start penalty. Phrase: “At high traffic volumes, most requests hit a warm start — cold starts only matter at low traffic or during scale-out events.”

Cloudflare Workers — Cloudflare’s edge function platform, running JavaScript and WASM on V8 isolates at Cloudflare’s 300+ PoPs. Features: KV storage, Durable Objects, R2 storage, D1 database.

Vercel Edge Functions — Vercel’s edge compute offering, running on the edge runtime (a subset of Node.js) at Vercel’s global network. Tightly integrated with Next.js middleware.

Caching and Routing

Edge caching strategy — The rules that determine what is cached at the edge, for how long, and when the cache is invalidated. A good edge caching strategy dramatically reduces origin load. Phrase: “Our edge caching strategy serves static pages from cache for 24 hours and uses stale-while-revalidate for product pages.”

CDN edge function — A function executed at a CDN’s edge node, typically to modify requests or responses, personalise content, or handle authentication before content is served from cache. Phrase: “The CDN edge function rewrites URLs and injects A/B test cookies before the request reaches the origin.”

Geo-routing — Directing traffic to different backends, content, or edge functions based on the user’s geographic location. Phrase: “Geo-routing sends EU users to the Frankfurt origin and US users to the Virginia origin — for GDPR data residency.”

Edge-side rendering (ESR) — Rendering HTML at the edge rather than at the origin or in the browser. Enables fast, personalised server-rendered pages without full origin server involvement. Phrase: “We use edge-side rendering for the homepage — it renders personalised content at the edge using geo and session data.”

Partial hydration at edge — A pattern where some components are rendered as static HTML at the edge and only interactive components are hydrated with JavaScript in the browser, minimising JavaScript payload. Phrase: “Partial hydration at edge gives us fast initial load and interactive components — without shipping a full React bundle for static content.”

Real Phrases from Edge Architecture Discussions

• “Route this middleware to the edge — it needs to run before the CDN cache check.”
• “The edge function adds personalisation headers; the origin reads them and renders the right variant.”
• “KV reads at the edge are eventually consistent — is that acceptable for this use case?”
• “Cold start latency is not a concern here — we use V8 isolates, not Lambda.”

Practice: Read the Cloudflare Workers documentation or Vercel Edge Functions guide and write a short design doc (150 words) for moving one part of a real or fictional application to the edge. Use at least seven terms from this post.

Expanding Your Understanding: Common Phrases & Nuances

Let’s be honest – when you’re learning a new technical domain, it’s not just about memorizing terms. It’s about understanding how those terms are actually used in conversations, design discussions, and documentation. As a developer, particularly one working with geographically distributed teams or complex architectures like edge computing, there are specific phrases and nuances that frequently appear – often subtly different from what you might initially expect.

One common area of confusion is the relationship between CDN (Content Delivery Network) and edge caching. Many developers assume they’re interchangeable, but they aren’t. A CDN distributes content across a global network to reduce latency for users worldwide. Edge caching, on the other hand, is specifically about storing copies of that content closer to the user – at an edge node itself – to further minimize response times and offload traffic from the origin server. Think of it this way: the CDN is the transportation system, while edge caching is a strategically placed warehouse along that route. You’ll frequently hear discussions about optimizing both, but understanding their distinct roles is crucial for designing efficient architectures. For example, a conversation might start with, “We need to increase our edge cache hit ratio by 15% – let’s look at how we can configure the V8 isolates to prioritize static assets.”

Another phrase you’ll encounter repeatedly is “cold start.” This isn’t just about a function taking time to execute; it refers specifically to the delay experienced when a serverless function, running on an edge node, is invoked for the first time or after a period of inactivity. The V8 isolate needs to initialize, pull dependencies, and become fully operational – this takes time, especially with larger functions. You might see a comment in a code review like: “Consider optimizing this function’s cold start performance by pre-warming it using a scheduled event trigger.” This highlights the need for proactive strategies rather than simply reacting to latency issues after they arise.

Finally, when discussing geo-routing and traffic management, phrases like “lowest cost path” or “optimal routing based on network conditions” are frequently used. It’s not just about directing users to the closest server; it’s a dynamic process that considers factors like bandwidth availability, latency fluctuations, and even potential network congestion.

# Example: Using curl to test latency from different locations (illustrative)
curl -s --url https://example.com/api/data  -H "x-geo: us-east-1"
curl -s --url https://example.com/api/data  -H "x-geo: eu-west-1"

This simple curl command (though simplified for demonstration) illustrates how geo-routing might be implemented – adding a header to request data from a specific region, allowing developers and architects to monitor performance across different geographic areas.