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

Edge Computing: battere la velocità della luce

La velocità della luce è un limite rigido. Come utilizzare Edge Functions (Vercel/Cloudflare) per eseguire la logica a 10 millisecondi di distanza dall'utente.

AB
Alex B.
Edge Computing: battere la velocità della luce

Se il tuo server è in Virginia (us-east-1) e il tuo utente è a Tokyo: *La richiesta percorre 10.000 km.

  • Latenza = ~150ms.
  • Andata e ritorno = ~300ms. Nessuna quantità di ottimizzazione del codice può correggere la fisica. L’unico modo per andare più veloci è ridurre la distanza fisica. L’Edge Computing sposta la logica da “The Server” (Un posto) a “The Edge” (Ovunque). Invece di 1 server in Virginia, hai codice in esecuzione su 500 server in 500 città. L’utente a Tokyo accede al server di Tokyo. Latenza = 10ms.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Edge Middleware (L’Interceptor)

In framework come Next.js, questo si chiama Middleware. Viene eseguito prima che la richiesta raggiunga il server principale o la cache. È estremamente leggero (runtime limitato, nessuna API Node.js). Casi d’uso:

  1. Personalizzazione:
    • Leggi il cookie: user_segment=vip.
    • Riscrivi l’URL: /home -> /home-vip.
    • Ciò avviene immediatamente al bordo. Nessuno sfarfallio lato client.
  2. Blocchi geografici/Routing:
    • “L’utente è in Francia?” -> Reindirizza a /fr.
    • “L’utente è nell’IP di Office?” -> Mostra ambiente di staging.
  3. Test A/B:
    • Traffico suddiviso 50/50.
    • Assegna cookie.

Il problema del database

L’esecuzione del codice sull’Edge è stata risolta (Vercel, Cloudflare Workers, AWS Lambda@Edge). Ma i dati di solito risiedono in un unico posto (il database primario).

  • Edge Function (Tokyo) -> Database (Virginia).
  • Abbiamo reintrodotto la latenza! SOLUZIONI:
  1. Repliche di lettura: inserisci un database di sola lettura a Tokyo. (Buono per i siti di contenuti).
  2. Database globali: utilizzare Turso (LibSQL) o Cloudflare D1. Replicano automaticamente i dati all’edge.
  3. Edge Caching: memorizza nella cache la risposta del database in Redis at the Edge (Upstash).

”Serverless” è uguale a “Edge”?

No.

  • Serverless (Lambda): genera un contenitore in una regione specifica (ad esempio, us-east-1). Gli avviamenti a freddo possono essere lenti (500 ms). Ha tutta la potenza di Node.js.
  • Edge (Lavoratori): genera un isolato (V8) nel data center più vicino. Gli avviamenti a freddo sono istantanei (0ms). Dispone di API limitate (API Web standard). Decisione sull’architettura:
  • Utilizza Edge per routing, controlli di autenticazione e logica semplice.
  • Utilizza Serverless per elaborazioni pesanti (ridimensionamento delle immagini, generazione di PDF).

4. Stato Edge: oggetti durevoli

I lavoratori di Cloudflare hanno introdotto gli oggetti durevoli. Ciò consente di memorizzare lo stato sul nodo periferico stesso. Caso d’uso: collaborazione in tempo reale (stile Google Documenti).

  1. L’utente A (Parigi) si connette a DO a Parigi.
  2. L’utente B (Londra) si connette a DO a Parigi (nodo attivo più vicino).
  3. Condividono una connessione WebSocket con una latenza di 10 ms.
  4. Lo stato (testo del documento) è archiviato nella RAM dell’Edge. Nessun viaggio di andata e ritorno in Virginia.

5. Il problema dell’invalidazione della cache

“Ci sono solo due cose difficili in informatica: l’invalidazione della cache e la denominazione delle cose.” Se memorizzi nella cache l’HTML su Edge, l’aggiornamento del sito è immediato per te, ma gli utenti vedono la versione precedente. Strategia: Stale-While-Revalidate (SWR).

  1. Edge serve il contenuto memorizzato nella cache (istantaneo).
  2. Edge recupera in modo asincrono nuovi contenuti da Origin.
  3. Edge aggiorna la cache.
  4. L’utente successivo vedrà il nuovo contenuto. Oppure utilizza Chiavi surrogate. Tagga il tuo contenuto (“prodotto-123”). Quando aggiorni il prodotto 123, indica al CDN di eliminare il tag “prodotto-123”.

7. Ottimizzazione dell’immagine all’edge

Tradizionalmente, ridimensioni le immagini sul server o utilizzi un servizio come Cloudinary. Ora, Edge può farlo. Cloudflare Images o Vercel Image Optimization vengono eseguiti all’edge. Rileva: “L’utente è su Android? Servire WebP.” “L’utente è su iPhone? Servi JPEG.” Si ridimensiona in base all’intestazione “larghezza”. Ciò scarica un enorme lavoro della CPU dal tuo server di origine. La tua origine fornisce un’immagine Master ad alta risoluzione. The Edge offre 50 varianti localizzate.

8. Rendering SEO all’Edge

I motori di ricerca (Googlebot) stanno migliorando in JS, ma l’HTML grezzo è ancora il re. Se disponi di una SPA personalizzata (app a pagina singola), puoi utilizzare Edge per il “pre-rendering” solo per i bot. Agente utente: Googlebot -> La funzione Edge esegue il rendering dell’HTML -> Restituisce una pagina statica. Agente utente: Chrome -> La funzione Edge funge da proxy -> Restituisce il pacchetto SPA. Questa è la Pubblicazione dinamica. Ti dà il SEO di un sito statico con la UX di un’app.

9. Iperpersonalizzazione al limite

“Ciao, [Nome]” è basilare. “Ciao, abbiamo visto che sta piovendo a Tokyo. Compri un ombrello?” è la personalizzazione dei bordi. Cerchiamo l’IP dell’utente -> API meteo (memorizzata nella cache su Edge). Riscriviamo lo stendardo dell’eroe per mostrare gli impermeabili. Poiché la logica viene eseguita a Tokyo (vicino all’utente), aggiunge 0 ms alla latenza rispetto a una pagina statica. Possiamo anche riordinare le griglie di prodotti in base al “Punteggio di affinità” memorizzato in un Edge Cookie.

10. Geofencing di conformità

GDPR (Europa) vs CCPA (California) vs PIPL (Cina). Le regole sulla sovranità dei dati sono rigide. “I dati degli utenti dalla Germania non devono lasciare la Germania.” Le funzioni Edge risolvono questo problema. Indirizziamo gli IP tedeschi al data center di Francoforte. La funzione Edge scrive su un database D1 locale a Francoforte. I dati non attraversano mai l’Atlantico. Ciò rende la “Conformità globale” una regola di routing, non un incubo legale.

11. WebAssembly (WASM) al limite

Gli isolati V8 sono veloci, ma sono JavaScript. A volte hai bisogno di potenza pura (Rust/C++). I lavoratori Cloudflare supportano WASM. Caso d’uso: ridimensionamento delle immagini (Photon), crittografia o inferenza AI (ONNX). Compila il tuo codice Rust su WASM e caricalo su Edge. Il Worker chiama la funzione WASM con prestazioni quasi native. Ciò ci consente di eseguire calcoli “pesanti” (come algoritmi di transcodifica video o personalizzazione) senza avviare una Lambda.

10. Perché Maison Code?

Noi di Maison Code siamo ossessionati dal Time to First Byte (TTFB). Non ci accontentiamo del “Abbastanza veloce”. Vogliamo “istantaneo”. Progettiamo le nostre soluzioni (Hydrogen/Remix) per sfruttare Edge per impostazione predefinita. Sappiamo quali intestazioni impostare (stale- while-revalidate), quali database utilizzare (Turso/D1) e come instradare il traffico a livello globale. Trasformiamo la Fisica nella tua alleata, non nella tua nemica.

12. Tagging lato server sull’edge

I pixel di marketing (Facebook CAPI, TikTok Events) vengono generalmente eseguiti nel browser. Rallentano la pagina e vengono bloccati dagli AdBlocker. Li spostiamo sul Edge.

  1. L’utente fa clic su “Acquista”.
  2. Il browser invia 1 beacon leggero a “edge.maisoncode.paris”.
  3. Edge Function inoltra l’evento a Facebook, TikTok, Google, Snapchat. Risultato:
  • Precisione dei dati al 100% (ignora AdBlock).
  • Blocco del thread principale da 0 ms.
  • Sicuro (chiavi API nascoste sul server).

13. Analisi dei costi perimetrali

“L’Edge è costoso?” In realtà, è più economico dei server tradizionali.

  • AWS Lambda: paghi in base alla durata (GB-secondi). Le partenze a freddo costano denaro.
  • Lavoratori Cloudflare: paghi per le richieste (milioni di operazioni). Il tempo della CPU è spesso gratuito (entro i limiti).
  • Nessun costo di inattività: non paghi per i server vuoti alle 3 del mattino. Per un sito ad alto traffico, il “Cache Hit Ratio” all’edge riduce il carico sul database di origine del 90%, riducendo significativamente il conto del database. Si ripaga da solo.

14. Lista di controllo della strategia Edge

Passare all’Edge?

  1. Identifica percorsi dinamici: quali pagine necessitano effettivamente di personalizzazione?
  2. Località database: il tuo DB è globale (Turso) o regionale (AWS RDS)?
  3. Gestione intestazioni: configura stale- while-revalidate.
  4. Gestione delle eccezioni: logica per eseguire il fallback sul contenuto statico se Edge fallisce.
  5. Logging: imposta i log drain (Cloudflare -> Datadog).
  6. CI/CD: distribuzione automatica su Edge su git push.
  7. Limite di costo: imposta limiti sulle richieste dei lavoratori per evitare sorprese nella fatturazione.
  8. Variabili d’ambiente: sincronizza i segreti con l’ambiente Edge.
  9. Avvii a freddo: misura la latenza P99.
  10. Fallback: se Edge non è attivo, la CDN fornisce contenuti obsoleti?

15. Conclusione

The Edge è il futuro del frontend. Stiamo spostando la logica dal Dispositivo dell’Utente (Client) e dal Server Centrale (Origine) nello spazio intermedio. Ciò abilita la “Velocità statica” con “Personalizzazione dinamica”. È il meglio di entrambi i mondi.

Latenza troppo alta?

Implementiamo strategie Edge Middleware per personalizzare i contenuti senza sacrificare il TTFB.

Premi sul bordo. Assumi i nostri architetti.