Che cosa sono l'edge computing e le funzioni serverless edge?

L’edge computing è un modello che esegue il calcolo vicino agli utenti o alle fonti di dati; le funzioni edge sono codice serverless eseguito nei PoP di un CDN. Il termine generale – definito in modo canonico da Shi et al. come calcolo collocato vicino alle fonti dei dati – copre sia l’IoT dei reparti produttivi sia l’infrastruttura MEC delle telecomunicazioni. Per chi sviluppa backend significa però qualcosa di preciso: piccole funzioni distribuite sugli stessi point of presence globali che usa un CDN, eseguite nel PoP più vicino a ogni richiesta – l’evoluzione del CDN, dalla cache dei contenuti all’esecuzione di codice.

Punti chiave

Una funzione edge, e il livello in cui vive

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Reject requests without credentials at the edge; full verification and data work go to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

La scheda JavaScript è la funzione edge stessa – Request/Response standard del web, nessun framework, intercettazione del traffico prima dell’origine. Le schede client mostrano l’altro lato dell’architettura: i dati applicativi continuano ad andare al backend di origine, perché è lì che vive il database – la frase a cui tutto questo articolo continua a tornare.

Isolate vs. container: perché l’edge parte in millisecondi

Migliaia di isolate condividono un unico processo di lunga durata per macchina – lo stesso meccanismo che tiene separate le schede del browser – quindi “avviare” una funzione significa creare un contesto, non far partire un runtime. È questa architettura, non i pool caldi, che permette alle piattaforme edge di dichiarare onestamente cold start quasi nulli. Il conto si legge nella terza e nella quarta riga: un confine di isolamento più debole (compensato da mitigazioni accurate) e un runtime in cui buona parte di npm non gira – nessun filesystem, nessun modulo nativo, nessuna valutazione dinamica, con la superficie portabile ormai standardizzata come Minimum Common API (ECMA-429).

Edge vs. origine: la divisione dei carichi

La parte onesta: il database resta in un unico posto

La sezione che le presentazioni dei fornitori omettono. Spostare il calcolo all’edge non sposta i dati – trasferisce il round trip da utente → server a funzione → database, e per i carichi che fanno molte chiamate è un peggioramento: una funzione edge a 5 ms dall’utente che manda cinque query sequenziali a un database a 150 ms consuma 750 ms dove una funzione regionale collocata accanto al database ne consumerebbe ~5. L’aritmetica spiega la discreta correzione di rotta del settore – alcune grandi piattaforme edge oggi raccomandano i propri runtime regionali per la maggior parte dei carichi e hanno aggiunto opzioni per ancorare le funzioni vicino al database, l’ammissione più chiara possibile che la località dei dati batte la località del calcolo. I rimedi parziali, in ordine di praticità: far girare all’origine il codice che consuma dati (la tabella di divisione qui sopra); raggruppare in un solo round trip quando il codice edge deve toccare i dati; e replicare le letture verso l’esterno con cache chiave-valore all’edge – trade-off di eventual consistency (coerenza finale) compresi. Le funzioni edge vincono quando si concludono all’edge; nel momento in cui devono interpellare l’origine a ogni richiesta, la geografia smette di giocare a loro favore.

Quando l’edge è sovra-ingegneria

La maggior parte delle applicazioni è un backend CRUD con una base utenti regionale – per loro un backend in una sola regione più un CDN per gli asset statici è più semplice e spesso più veloce end-to-end di un livello edge che fa un round trip verso lo stesso database. Le funzioni edge si guadagnano il posto quando la logica si conclude all’edge per un pubblico distribuito nel mondo su un percorso in cui la latenza si vede – tre condizioni, tutte necessarie. Il modello di costo racconta la stessa storia dall’altro lato: le piattaforme edge fatturano a richiesta più i millisecondi di CPU (poco per una logica di gateway sottile), mentre le funzioni regionali fatturano la durata reale – compreso il tempo che il codice passa ad aspettare il database accanto al quale avrebbe dovuto stare.

Casi d’uso comuni

• Barriere di autenticazione – verificare un token di sessione nel PoP; le richieste non autenticate non attraversano mai l’oceano.
• Geo-personalizzazione – lingua, valuta e routing di conformità decisi a pochi millisecondi dall’utente.
• Ripartizione A/B e feature flag – assegnazione del cookie all’edge, coerente prima che la pagina si carichi.
• Rate limiting e difesa dai bot – assorbire gli abusi al perimetro, con contatori per PoP in un KV edge.
• Edge computing in senso ampio – l’accezione IoT/telecomunicazioni: sensori di fabbrica e infrastruttura 5G che elaborano in locale, un tema da articolo a sé, riconosciuto qui in una riga.

Conviene usare le funzioni edge? Matrice decisionale

Limiti e trade-off

• Il runtime è un sottoinsieme. Solo API standard del web; gli ORM con binding nativi, le librerie per le immagini e il codice che dipende dal filesystem non girano – conviene controllare l’albero delle dipendenze prima di impegnarsi.
• I tetti sulla CPU sono stretti. Il budget è di poche decine di millisecondi di calcolo; le funzioni edge instradano il traffico, non lo elaborano.
• Lo stato sta altrove, per scelta progettuale. Ogni esigenza con stato finisce all’origine o in un KV edge con semantica di eventual consistency – nessuna delle due è gratis.
• Il debug è distribuito. Riprodurre un bug che si presenta solo in un PoP, sotto una sola geografia, è una disciplina a parte; la contromisura è centralizzare i log di ogni sede.
• Il pendolo oscilla. Le impostazioni predefinite “edge prima di tutto” sono già state riviste una volta; l’edge va trattato come uno strumento preciso per la logica di gateway, non come un’identità architetturale.

L’edge su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Nello schema a tre livelli che questo articolo disegna, Back4app è l’origine fatta bene: il database e la logica di business in Cloud Code vivono insieme – la collocazione comune che rende veloce il lavoro sui dati – dietro un CDN che serve file e asset statici dagli stessi PoP che userebbe un livello edge. Le funzioni edge si inseriscono poi davanti, come logica di gateway sottile, dove le tre condizioni valgono: un redirect qui, un controllo di token là, e poi il passaggio a un’origine che possiede i dati e applica le ACL a ogni richiesta. La lezione di architettura che insegna la sezione onesta – il calcolo vicino all’utente, il lavoro sui dati vicino ai dati – è esattamente questa divisione, con ogni livello che fa la parte favorita dalla geografia.