Edge compute : Workers, Deno Deploy, Fastly

[khalilbenaz]

---

lede: Cloudflare Workers, Deno Deploy et Fastly Compute exécutent du code au plus près de l'utilisateur — mais leurs modèles d'isolation et de runtime dictent ce qu'on peut y faire.
lede_en: Cloudflare Workers, Deno Deploy and Fastly Compute run code closest to the user — but their isolation and runtime models dictate what you can build.
title_en: Edge compute: Workers, Deno Deploy, Fastly

Ce que « edge » veut vraiment dire

L'edge compute exécute votre code sur des centaines de points de présence répartis mondialement, à quelques millisecondes de l'utilisateur, au lieu d'une poignée de régions cloud. La promesse est double : latence minimale (le code s'exécute près de qui le demande) et scaling implicite (pas de serveur à provisionner). Mais l'edge n'est pas un serveur classique rétréci : c'est un modèle d'exécution contraint. Comprendre ces contraintes est la différence entre un design qui vole et un qui se cogne à un mur en production.

Trois modèles d'isolation

Le clivage technique fondamental entre les acteurs de 2026 est comment ils isolent le code des tenants :

• Cloudflare Workers — isolats V8. Chaque requête s'exécute dans un isolat JavaScript léger, pas un conteneur ni une VM. Démarrage quasi instantané (pas de cold start perceptible), mais on vit dans un runtime JS/WASM, pas Node complet.
• Deno Deploy — isolats V8 aussi, mais avec l'API Deno et une forte compatibilité Web-standard. L'expérience développeur TypeScript-first est la plus soignée.
• Fastly Compute — WebAssembly via le runtime Wasmtime. On compile depuis Rust, Go, JavaScript ou autre vers WASM. Isolation par instance WASM, cold start sub-milliseconde annoncé.

Les isolats V8 (Cloudflare, Deno) partagent un process et se protègent par les frontières du moteur JS. Le WASM (Fastly) offre une isolation plus proche du bare-metal et une liberté de langage plus large.

Ce qu'on peut vraiment y faire

L'edge excelle sur une classe de charges bien délimitée :

• Manipulation de requête/réponse — réécriture d'en-têtes, redirections, A/B testing, feature flags.
• Authentification et autorisation — vérifier un JWT avant de laisser passer vers l'origine.
• Personnalisation légère — géolocalisation, adaptation par device, contenu par pays.
• API de lecture avec cache — servir depuis le KV/cache edge, tomber sur l'origine seulement en miss.

// Cloudflare Worker : géo-routage + cache edge
export default {
  async fetch(request, env) {
    const country = request.cf?.country ?? "US";
    const cacheKey = new Request(request.url + country, request);
    const cache = caches.default;
    let res = await cache.match(cacheKey);
    if (!res) {
      res = await fetch(`https://origin/${country}/data`);
      res = new Response(res.body, res);
      res.headers.set("Cache-Control", "s-maxage=60");
      await cache.put(cacheKey, res.clone());
    }
    return res;
  },
};

Comparaison honnête

Critère	Cloudflare Workers	Deno Deploy	Fastly Compute
Isolation	Isolats V8	Isolats V8	WASM (Wasmtime)
Langages	JS/TS/WASM	JS/TS	Rust/Go/JS→WASM
État	KV, Durable Objects, D1, R2	KV, Postgres	KV, config store
Cold start	Négligeable	Négligeable	Sub-ms annoncé
Écosystème stockage	Le plus large	En croissance	Plus ciblé

Cloudflare gagne sur l'écosystème d'état : Durable Objects (état cohérent par clé), D1 (SQLite distribué), R2 (objet compatible S3, sans egress). C'est ce qui permet de bâtir des applis complètes, pas juste du middleware. Deno séduit par la pureté TypeScript et l'alignement Web-standard. Fastly vise la performance brute et la liberté de langage via WASM.

Pièges et limites

• Pas de Node complet. Beaucoup de librairies npm supposant des API Node (fs, net brut, certains crypto) ne tournent pas. Les couches de compat progressent mais ne couvrent pas tout.
• Budget CPU strict par requête. L'edge n'est pas fait pour le calcul lourd ou les traitements longs. Une inférence ML massive ou un batch appartient ailleurs.
• La cohérence de l'état distribué est un piège. Un KV edge est éventuellement cohérent ; croire à une écriture immédiatement lisible partout est l'erreur classique. Durable Objects existe précisément pour les cas nécessitant une cohérence forte par clé.
• Débogage distribué. Reproduire un bug qui ne survient que sur un PoP précis est pénible ; l'observabilité edge reste plus jeune que côté serveur.

Verdict

En 2026, l'edge n'a pas remplacé le serveur — il a créé une nouvelle couche entre le client et l'origine. Placez-y ce qui gagne à être proche de l'utilisateur et tient dans un budget CPU serré : routage, auth, personnalisation, cache. Pour bâtir une appli complète à l'edge, Cloudflare mène par la richesse de son état ; Deno pour l'ergonomie TypeScript ; Fastly pour la performance WASM et le choix du langage. Le mauvais réflexe reste de vouloir tout y mettre — l'edge punit le calcul lourd sans pitié.

What "edge" really means

Edge compute runs your code on hundreds of points of presence worldwide, within a few milliseconds of the user, instead of a handful of cloud regions. The promise is twofold: minimal latency (code runs near whoever asks) and implicit scaling (no server to provision). But the edge is not a shrunk classic server: it is a constrained execution model. Understanding those constraints is the difference between a design that flies and one that hits a wall in production.

Three isolation models

The fundamental technical divide between the 2026 players is how they isolate tenant code:

• Cloudflare Workers — V8 isolates. Each request runs in a lightweight JavaScript isolate, not a container or VM. Near-instant startup (no perceptible cold start), but you live in a JS/WASM runtime, not full Node.
• Deno Deploy — V8 isolates too, but with the Deno API and strong Web-standard compatibility. The TypeScript-first developer experience is the most polished.
• Fastly Compute — WebAssembly via the Wasmtime runtime. You compile from Rust, Go, JavaScript or others to WASM. Isolation per WASM instance, sub-millisecond cold start claimed.

V8 isolates (Cloudflare, Deno) share a process and protect via the JS engine's boundaries. WASM (Fastly) offers isolation closer to bare metal and broader language freedom.

What you can actually build

The edge excels at a well-bounded class of workloads:

• Request/response manipulation — header rewriting, redirects, A/B testing, feature flags.
• Authentication and authorization — verifying a JWT before letting it reach origin.
• Light personalization — geolocation, device adaptation, per-country content.
• Read APIs with caching — serving from edge KV/cache, hitting origin only on miss.

// Cloudflare Worker: geo-routing + edge cache
export default {
  async fetch(request, env) {
    const country = request.cf?.country ?? "US";
    const cacheKey = new Request(request.url + country, request);
    const cache = caches.default;
    let res = await cache.match(cacheKey);
    if (!res) {
      res = await fetch(`https://origin/${country}/data`);
      res = new Response(res.body, res);
      res.headers.set("Cache-Control", "s-maxage=60");
      await cache.put(cacheKey, res.clone());
    }
    return res;
  },
};

An honest comparison

Criterion	Cloudflare Workers	Deno Deploy	Fastly Compute
Isolation	V8 isolates	V8 isolates	WASM (Wasmtime)
Languages	JS/TS/WASM	JS/TS	Rust/Go/JS→WASM
State	KV, Durable Objects, D1, R2	KV, Postgres	KV, config store
Cold start	Negligible	Negligible	Sub-ms claimed
Storage ecosystem	Broadest	Growing	More targeted

Cloudflare wins on the state ecosystem: Durable Objects (coherent per-key state), D1 (distributed SQLite), R2 (S3-compatible object, no egress). That is what lets you build full apps, not just middleware. Deno appeals through TypeScript purity and Web-standard alignment. Fastly targets raw performance and language freedom via WASM.

Pitfalls and limits

• No full Node. Many npm libraries assuming Node APIs (fs, raw net, certain crypto) won't run. Compatibility layers keep improving but don't cover everything.
• Strict per-request CPU budget. The edge is not for heavy computation or long-running work. Massive ML inference or a batch job belongs elsewhere.
• Distributed-state consistency is a trap. An edge KV is eventually consistent; believing a write is immediately readable everywhere is the classic mistake. Durable Objects exists precisely for cases needing strong per-key consistency.
• Distributed debugging. Reproducing a bug that only occurs on a specific PoP is painful; edge observability is younger than server-side.

Verdict

In 2026, the edge has not replaced the server — it created a new layer between client and origin. Put there what benefits from proximity to the user and fits a tight CPU budget: routing, auth, personalization, caching. To build a full app at the edge, Cloudflare leads on state richness; Deno on TypeScript ergonomics; Fastly on WASM performance and language choice. The wrong instinct remains wanting to put everything there — the edge punishes heavy compute without mercy.