---
term: 'Edge computing e funzioni serverless edge'
seoTitle: 'Edge computing e funzioni edge: isolate, latenza, limiti'
headline: 'Che cosa sono l''edge computing e le funzioni serverless edge?'
slug: edge-computing
category: backend-compute
shortDefinition: '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.'
relatedTerms:
  - cdn-content-delivery-network
  - cloud-code-serverless-functions
  - serverless-architecture
  - serverless-cold-starts
contrastsWith:
  - serverless-architecture
aboutTerms:
  - 'Edge Functions'
  - 'V8 Isolates'
  - 'Points of Presence (POPs)'
faq:
  - question: 'Che cos''è l''edge computing, in parole semplici?'
    answer: 'Eseguire il calcolo vicino al punto in cui i dati nascono o in cui si trovano gli utenti, invece che in un unico data center lontano. Meno distanza significa meno millisecondi e meno banda – l''idea sta tutta nella geografia. Il termine copre i sensori IoT, l''infrastruttura delle telecomunicazioni e, per chi sviluppa sul web, il codice che gira nei point of presence di un CDN.'
  - question: 'Che cos''è una funzione edge?'
    answer: 'Una piccola funzione serverless distribuita sui point of presence globali di un CDN ed eseguita nella sede più vicina a ogni richiesta – tipicamente per intercettare il traffico HTTP e reindirizzare, personalizzare o autenticare prima che arrivi al backend di origine.'
  - question: 'Qual è la differenza tra funzioni edge e funzioni serverless?'
    answer: 'Entrambe sono functions-as-a-service; si distinguono per il luogo (centinaia di sedi contro una sola regione), il runtime (isolate leggeri con API standard del web contro runtime completi in container), i cold start (quasi nulli contro centinaia di millisecondi) e i limiti (tetti stretti su CPU e dimensioni contro minuti e gigabyte).'
  - question: 'Che cosa sono gli isolate V8?'
    answer: 'Contesti JavaScript leggeri e in sandbox – lo stesso meccanismo che separa le schede del browser – eseguiti a migliaia dentro un unico processo di lunga durata. Ognuno ha il proprio heap e le proprie variabili globali, parte in meno di cinque millisecondi con pochi megabyte di overhead e non richiede l''avvio di un container o di una VM: è il motivo per cui le piattaforme edge dichiarano cold start praticamente nulli.'
  - question: 'Quali sono i limiti dei runtime edge?'
    answer: 'Un sottoinsieme delle API standard del web – fetch, Request/Response, stream, WebCrypto – senza filesystem, senza moduli nativi e senza valutazione dinamica del codice; tetti stretti sul tempo di CPU (poche decine di millisecondi è la norma) e limiti ridotti sulla dimensione del bundle. Molti pacchetti diffusi, dagli ORM con binding nativi alle librerie per le immagini, semplicemente non girano lì.'
  - question: 'Che cosa va all''edge e che cosa resta all''origine?'
    answer: 'All''edge: la logica di gateway stateless vicino all''utente – controlli sui token, redirect, routing geografico, ripartizione A/B, riscrittura degli header, rate limiting. All''origine: tutto ciò che ha stato ed è transazionale – letture e scritture sul database, logica di business, elaborazioni pesanti. La regola empirica: il calcolo vicino all''utente, il lavoro sui dati vicino ai dati.'
  - question: 'Il database rovina la latenza dell''edge?'
    answer: 'Spesso sì – spostare il calcolo all''edge non sposta i dati. Una funzione edge a Tokyo che interroga un database in Virginia paga un intero round trip transpacifico per ogni query; cinque query sequenziali trasformano una funzione da cinque millisecondi in una da 750 millisecondi. I rimedi: girare vicino ai dati, raggruppare in un solo round trip, oppure mettere in cache le letture all''edge.'
  - question: 'Un CDN è la stessa cosa dell''edge computing?'
    answer: 'Un CDN mette in cache e serve contenuti statici nei point of presence; l''edge computing esegue il codice in quelle stesse sedi. Le funzioni edge sono l''evoluzione programmabile del CDN – stessa geografia, logica attiva al posto di una cache passiva.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Shi et al. — Edge Computing: Vision and Challenges (IEEE IoT Journal)'
    url: 'https://doi.org/10.1109/JIOT.2016.2579198'
  - name: 'ETSI — Multi-access Edge Computing (MEC)'
    url: 'https://www.etsi.org/technologies/multi-access-edge-computing'
  - name: 'WinterTC — Minimum Common Web Platform API'
    url: 'https://min-common-api.proposal.wintertc.org/'
  - name: 'V8 documentation'
    url: 'https://v8.dev/'
  - name: 'Edge computing — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Edge_computing'
cta:
  title: 'L''origine fatta bene, l''edge dove rende'
  text: 'Back4app è il livello di origine dello schema a tre livelli: database, autenticazione e logica di business serviti da un''API dietro un CDN – così le funzioni edge, dove ti servono davvero, restano logica di gateway sottile invece di un secondo backend.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: edge-computing-edge-functions
---

**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.](https://doi.org/10.1109/JIOT.2016.2579198) come calcolo collocato vicino alle fonti dei dati – copre sia l'IoT dei reparti produttivi sia l'infrastruttura [MEC](https://www.etsi.org/technologies/multi-access-edge-computing) delle telecomunicazioni. Per chi sviluppa backend significa però qualcosa di preciso: piccole funzioni distribuite sugli stessi point of presence globali che usa un [CDN](/glossary/it/cdn/), eseguite nel PoP più vicino a ogni richiesta – l'evoluzione del CDN, dalla cache dei contenuti all'esecuzione di codice.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Perché l'edge è veloce | Fisica – l'RTT è distanza; un PoP vicino vale ~5 ms, un oceano ~150 ms |
| Il trucco del runtime | Isolate V8: sandbox in stile scheda del browser, avvio in ~ms, nessun container da avviare |
| Che cosa ci sta bene | Logica di gateway stateless – controlli di autenticazione, redirect, personalizzazione |
| Che cosa non ci sta | Il lavoro sui dati – il database resta in un unico posto |
| L'avvertenza onesta | L'edge sposta il round trip; solo la strategia sui dati lo elimina |

## Una funzione edge, e il livello in cui vive

**JavaScript:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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

| | Isolate V8 (edge) | Container / micro-VM (FaaS regionale) |
| --- | --- | --- |
| Avvio | **sotto i 5 ms** – creare un contesto JS | 100–1.000 ms – avviare il runtime, [cold start](/glossary/it/cold-start-serverless/) |
| Memoria per tenant | ~2 MB | 30–50 MB e oltre |
| Confine di isolamento | Sandbox nel processo (tecnologia delle schede del browser) | Sistema operativo/hypervisor – più solido |
| Superficie di API | Sottoinsieme standard del web | Runtime completo del linguaggio |
| Tetti di esecuzione | Decine di ms di CPU, bundle piccoli | Minuti, gigabyte |
| Adatto a | Logica di gateway per richiesta | Carichi applicativi veri |

Migliaia di isolate condividono un unico processo di lunga durata per macchina – lo [stesso meccanismo](https://v8.dev/) 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](https://min-common-api.proposal.wintertc.org/) (ECMA-429).

## Edge vs. origine: la divisione dei carichi

| Carico di lavoro | Gira | Perché |
| --- | --- | --- |
| Controlli su token/sessione, blocco dei bot | **All'edge** | Respingere il traffico indesiderato prima che attraversi un oceano |
| Redirect, routing geografico, ripartizione A/B | **All'edge** | Per richiesta, stateless, con latenza visibile |
| Riscrittura di header/cookie, logica di cache | **All'edge** | L'habitat naturale del CDN |
| Letture e scritture sul database | **All'origine** | I dati sono lì; altrimenti un RTT per query |
| Logica di business, transazioni | **All'origine** | Con stato, a più passaggi, serve il [runtime completo](/glossary/it/cloud-code-funzioni-serverless/) |
| Elaborazione di media, attività lunghe | **All'origine** | I tetti sulla CPU lo vietano all'edge |

## 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.

```mermaid
flowchart LR
  accTitle: Funzioni edge davanti a un'origine e a un database centrali
  accDescr: Gli utenti si collegano al point of presence più vicino, dove le funzioni edge gestiscono la logica di gateway come i redirect e i controlli di autenticazione in pochi millisecondi. Le richieste che hanno bisogno di dati continuano verso il backend di origine e il database centrali, pagando una volta sola il viaggio geografico di round trip, mentre gli asset statici vengono serviti dalla cache del CDN negli stessi point of presence.
  U1["Utente (Tokyo)"] --> P1["PoP più vicino<br/>fn edge: auth, redirect ~5 ms"]
  U2["Utente (Berlino)"] --> P2["PoP più vicino<br/>fn edge + cache CDN"]
  P1 -->|"dati: un solo round trip,<br/>raggruppato"| O["Backend di origine<br/>+ database (una regione)"]
  P2 -->|"statico: servito<br/>dalla cache"| P2
  P2 --> O
```

## 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](/glossary/it/json-web-token-jwt/) 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

| Situazione | Dove conviene |
| --- | --- |
| Utenti globali, logica di gateway con latenza visibile | Edge – gioca in casa |
| Logica che si conclude all'edge (senza database) | Edge |
| Molti accessi al database a ogni richiesta | Origine – sempre |
| Base utenti regionale, app CRUD standard | Origine + CDN; l'edge non aggiunge nulla |
| Dipendenze pesanti, moduli nativi, CPU prolungata | Origine – il runtime vieta l'edge |
| Asset statici | La [cache del CDN](/glossary/it/cdn/) – non serve nessuna funzione |

## 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](/glossary/it/cloud-code-funzioni-serverless/) 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](/glossary/it/liste-di-controllo-degli-accessi-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.