MAISON CODE .
/ Tech · Performance · Edge · Cloud · Architecture

Edge Computing: Beating the Speed of Light

The speed of light is a hard limit. How to use Edge Functions (Vercel/Cloudflare) to run logic 10 milliseconds away from your user.

AB
Alex B.
Edge Computing: Beating the Speed of Light

If your server is in Virginia (us-east-1) and your user is in Tokyo:

  • Request travels 10,000 km.
  • Latency = ~150ms.
  • Round trip = ~300ms. No amount of code optimization can fix physics. The only way to go faster is to reduce the physical distance. Edge Computing moves the logic from “The Server” (One place) to “The Edge” (Everywhere). Instead of 1 server in Virginia, you have code running on 500 servers in 500 cities. The user in Tokyo hits the Tokyo server. Latency = 10ms.

Edge Middleware (The Interceptor)

In frameworks like Next.js, this is called Middleware. It runs before the request hits the main server or the cache. It is extremely lightweight (Limited runtime, no Node.js APIs). Use Cases:

  1. Personalization:
    • Read cookie: user_segment=vip.
    • Rewrite URL: /home -> /home-vip.
    • This happens instantly at the edge. No client-side flicker.
  2. Geo-Blocking / Routing:
    • “User is in France?” -> Redirect to /fr.
    • “User is in Office IP?” -> Show Staging Environment.
  3. A/B Testing:
    • Split traffic 50/50.
    • Assign cookie.

The Database Problem

Running code at the Edge is solved (Vercel, Cloudflare Workers, AWS Lambda@Edge). But data usually lives in one place (The Primary Database).

  • Edge Function (Tokyo) -> Database (Virginia).
  • We reintroduced the latency! SOLUTIONS:
  1. Read Replicas: Put a Read-Only database in Tokyo. (Good for content sites).
  2. Global Databases: Use Turso (LibSQL) or Cloudflare D1. They replicate data to the edge automatically.
  3. Edge Caching: Cache the database response in Redis at the Edge (Upstash).

Is “Serverless” the same as “Edge”?

No.

  • Serverless (Lambda): Spawns a container in a specific region (e.g., us-east-1). Cold starts can be slow (500ms). Has full Node.js power.
  • Edge (Workers): Spawns an isolate (V8) in the nearest data center. Cold starts are instant (0ms). Has limited API (Standard Web API). Architecture Decision:
  • Use Edge for Routing, Auth Checks, and simple logic.
  • Use Serverless for heavy processing (Image resizing, PDF generation).

4. Edge State: Durable Objects

Cloudflare Workers introduced Durable Objects. This allows you to store state on the edge node itself. Use Case: Real-Time Collaboration (Google Docs style).

  1. User A (Paris) connects to DO in Paris.
  2. User B (London) connects to DO in Paris (nearest active node).
  3. They share a WebSocket connection with 10ms latency.
  4. The state (document text) is stored in RAM on the Edge. No round trip to Virginia.

5. The Cache Invalidation Problem

“There are only two hard things in Computer Science: Cache Invalidation and Naming Things.” If you cache HTML at the Edge, updating the site is instant for you, but users see the old version. Strategy: Stale-While-Revalidate (SWR).

  1. Edge serves cached content (Instant).
  2. Edge asynchronously fetches new content from Origin.
  3. Edge updates the cache.
  4. Next user sees new content. Or use Surrogate Keys. Tag your content (product-123). When you update product 123, tell the CDN to purge tag product-123.

7. Image Optimization at the Edge

Traditionally, you resize images on the server or use a service like Cloudinary. Now, the Edge can do it. Cloudflare Images or Vercel Image Optimization runs at the edge. It detects: “User is on Android? Serve WebP.” “User is on iPhone? Serve JPEG.” It resizes based on the width header. This offloads massive CPU work from your origin server. Your origin serves one high-res Master image. The Edge serves 50 localized variants.

8. SEO Rendering at the Edge

Search Engines (Googlebot) are getting better at JS, but raw HTML is still king. If you have a customized SPA (Single Page App), you can use the Edge to “Pre-render” just for bots. User-Agent: Googlebot -> Edge function renders HTML -> Returns Static Page. User-Agent: Chrome -> Edge function acts as proxy -> Returns SPA Bundle. This is Dynamic Serving. It gives you the SEO of a static site with the UX of an app.

9. Hyper-Personalization at the Edge

“Hello, [Name]” is basic. “Hello, we see it’s raining in Tokyo. Buy an umbrella?” is Edge Personalization. We look up the User’s IP -> Weather API (cached at Edge). We rewrite the Hero Banner to show raincoats. Because the logic runs in Tokyo (near the user), it adds 0ms to the latency compared to a static page. We can also reorder product grids based on “Affinity Score” stored in an Edge Cookie.

10. Compliance Geofencing

GDPR (Europe) vs CCPA (California) vs PIPL (China). Data Sovereignty rules are strict. “User data from Germany must not leave Germany.” Edge functions solve this. We route German IPs to the Frankfurt Data Center. The Edge Function writes to a local D1 Database in Frankfurt. The data never crosses the Atlantic. This makes “Global Compliance” a routing rule, not a legal nightmare.

11. WebAssembly (WASM) at the Edge

V8 Isolates are fast, but they are JavaScript. Sometimes you need raw power (Rust/C++). Cloudflare Workers support WASM. Use Case: Image resizing (Photon), Cryptography, or AI Inference (ONNX). You compile your Rust code to WASM and upload it to the Edge. The Worker calls the WASM function with near-native performance. This allows us to run “Heavy” computation (like video transcoding or personalization algorithms) without spinning up a Lambda.

Why Maison Code Discusses This

At Maison Code, we are obsessed with Time to First Byte (TTFB). We don’t settle for “Fast enough”. We want “Instant”. We architect our solutions (Hydrogen/Remix) to leverage the Edge by default. We know which headers to set (stale-while-revalidate), which databases to use (Turso/D1), and how to route traffic globally. We turn Physics into your ally, not your enemy.

12. Server-Side Tagging at the Edge

Marketing pixels (Facebook CAPI, TikTok Events) usually run in the browser. They slow down the page and get blocked by AdBlockers. We move them to the Edge.

  1. User clicks “Purchase”.
  2. Browser sends 1 lightweight beacon to edge.maisoncode.paris.
  3. Edge Function forwards event to Facebook, TikTok, Google, Snapchat. Result:
  • 100% Data Accuracy (Bypasses AdBlock).
  • 0ms Main Thread Blocking.
  • Secure (API Keys hidden on server).

13. Edge Cost Analysis

“Is the Edge expensive?” Actually, it’s cheaper than traditional servers.

  • AWS Lambda: You pay for duration (GB-seconds). Cold starts cost money.
  • Cloudflare Workers: You pay for requests (million ops). CPU time is often free (within limits).
  • No Idle Cost: You don’t pay for empty servers at 3 AM. For a high-traffic site, the “Cache Hit Ratio” at the edge reduces the load on your Origin DB by 90%, lowering your database bill significantly. It pays for itself.

14. Edge Strategy Checklist

Moving to the Edge?

  1. Identify Dynamic Routes: Which pages actually need personalization?
  2. Database Locality: Is your DB Global (Turso) or Regional (AWS RDS)?
  3. Header Management: Configure stale-while-revalidate.
  4. Exception Handling: Logic to fallback to static content if Edge fails.
  5. Logging: Set up Log Drains (Cloudflare -> Datadog).
  6. CI/CD: Auto-deploy to Edge on git push.
  7. Cost Cap: Set limits on Workers requests to prevent billing surprise.
  8. Environment Variables: Sync secrets to the Edge environment.
  9. Cold Starts: Measure P99 latency.
  10. Fallbacks: If Edge is down, does the CDN serve stale content?

15. Conclusion

The Edge is the future of the Frontend. We are moving logic out of the User’s Device (Client) and out of the Central Server (Origin) into the space in between. This enables “Static Speed” with “Dynamic Personalization”. It is the best of both worlds.

Latency too high?

We implement Edge Middleware strategies to personalize content without sacrificing TTFB.

Hire our Architects.