Quattro anni dopo che "edge functions" è diventato un buzzword, la categoria è matura. Quattro player seri, quattro filosofie. Vediamo dove siamo nel 2026.
Cloudflare Workers
Il leader di mercato. 320+ PoP globali, prezzi prevedibili (5 USD/mese fino a 10M req), V8 isolates per cold start praticamente nullo. Vince su: latenza globale, scalabilità improvvisa, integrazione con storage edge (R2, KV, D1). Limite: API non Node-compatibile al 100%, alcune librerie non funzionano.
Vercel Edge
Il più comodo per chi sviluppa Next.js. Build edge ovunque ha senso, fallback Node automatico. Vince su: DX integrata con Next.js, deploy frictionless. Limite: pricing che cresce velocemente, lock-in moderato.
Deno Deploy
Stable e maturo da 2 anni. TypeScript-first, Web Standard APIs ovunque. Vince su: developer experience, sicurezza out-of-the-box. Limite: ecosistema Node-style ancora marginale, hosting più piccolo.
Bun Deploy
Lanciato in beta a fine 2025. Punta a essere il "cloud per Bun" con performance estreme. Vince su: velocità di esecuzione su carichi compute. Limite: ancora giovane, copertura globale limitata.
La nostra matrice
| Caso | Scelta |
|---|---|
| App Next.js già su Vercel | Vercel Edge |
| Workload globale, latenza primaria | Cloudflare Workers |
| API edge con SQLite globale | Cloudflare Workers + D1 |
| App TypeScript pure, no Next.js | Deno Deploy |
| Microservizi Bun con stato in-memory | Bun Deploy |
Cosa NON fare a 2026
Non spostare a edge un'app monolitica solo perché è "moderno". Edge è ottimo quando: latenza globale conta, le request sono molte e brevi, lo stato è poco. Non è ottimo quando: un'app legge molto da un database centrale (le query attraversano l'oceano), le sessioni utente sono pesanti, i carichi sono CPU-bound.
L'errore frequente
Mettere edge functions davanti a un Postgres centrale in EU. Risultato: latenza peggiore di un Node tradizionale ben posizionato. La regola: edge ha senso quando lo stato è anche edge.