Che cos'è un backend? Il lato server di un'applicazione, spiegato

Un backend è un sistema lato server: codice, database e infrastruttura che gestiscono le richieste di un’app e ne conservano i dati dietro l’interfaccia. Ogni software con degli utenti ha due metà. La metà che vedono e toccano – schermate, pulsanti, moduli – è il frontend.

La metà che non vedono mai, quella che decide che cosa i pulsanti possono fare e ricorda che cosa è successo dopo che l’app è stata chiusa, è il backend. La vecchia analogia del meccanico regge ancora: chi guida lavora sul cruscotto, il meccanico lavora sul motore.

Questa voce parla del motore.

Punti chiave

Una richiesta, da un capo all’altro

Il modo più chiaro per vedere un backend è osservare una richiesta che lo attraversa. Un utente tocca “mostra le mie attività aperte”; ecco che cosa succede dall’altra parte dell’API:

GET /classes/Todo?where={"done":false} HTTP/1.1    ← il frontend chiede
Authorization: Bearer eyJhbGci…                     ← chi sta chiedendo

  backend ─┬─ livello API         analizza la richiesta, verifica il token
           ├─ autorizzazione      questo utente può leggere queste righe?
           ├─ logica di business  applica le regole (solo le attività del chiamante)
           ├─ livello dati        interroga il database, dà forma al risultato
           └─ risposta            200 OK + JSON, in meno di 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

La stessa conversazione dal lato del frontend, attraverso un SDK che la trasforma in una riga per piattaforma:

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. backend

La distinzione più cercata, in una tabella:

Quell’ultima riga è quella che conta per la sicurezza: tutto ciò che sta nel frontend può essere letto e modificato dall’utente. Per questo validazione, permessi e segreti appartengono al backend, e per questo ogni chiamata API viene trattata come non attendibile finché il server non l’ha verificata.

Lato client e lato server

I due termini non sono due tipi di backend; sono le due estremità di ogni richiesta. Il lato client è qualunque codice giri sul dispositivo dell’utente – disegnare l’interfaccia, conservare lo stato temporaneo, inviare richieste.

Il lato server è qualunque codice giri su macchine che l’utente non può raggiungere – ricevere quelle richieste, eseguire la logica vera, leggere e scrivere il database e rispondere. “Backend” e “lato server” si usano in modo intercambiabile per quella seconda metà, e questa voce fa lo stesso.

Di che cosa è fatto un backend

L’inquadramento classico chiama il frontend livello di presentazione e il backend livello di accesso ai dati, e descrive il backend come tre cose che lavorano insieme: le risorse hardware, il software che vi gira sopra e l’infrastruttura di rete fra queste e l’utente.

È ancora vero, ma è più utile leggere un backend come una pila di responsabilità, la maggior parte delle quali esiste in ogni prodotto a prescindere dalle dimensioni:

• Livello API – il contratto pubblico: endpoint REST o GraphQL che il frontend e gli altri sistemi chiamano.
• Logica di business – le regole che fanno del prodotto quel prodotto: che cos’è un ordine valido, chi può approvare che cosa, come si calcola un punteggio.
• Livello dati – il database e il codice che lo modella, lo interroga e lo migra.
• Autenticazione e autorizzazione – chi è il chiamante e che cosa può fare, applicate su ogni richiesta.
• Lavoro in background – job e pianificazioni per tutto ciò che non dovrebbe bloccare una richiesta: email, report, sincronizzazioni, pulizie.
• Infrastruttura – i server, i container o le funzioni su cui gira tutto, più deployment, logging, monitoring, backup e scalabilità.

I primi cinque sono lavoro di prodotto. Il sesto è operatività, ed è la parte che i modelli di hosting moderni esistono per eliminare.

Architetture di backend

La versione originale di questo argomento descriveva tre famiglie – serverless, orientata ai server e decentralizzata – e la tassonomia regge ancora. Quello che è cambiato è la scelta predefinita: nel 2026 la famiglia serverless è il punto di partenza della maggior parte dei nuovi prodotti, e “orientato ai server” significa sempre più container anziché macchine.

Backend basati su server. Il team esegue il provisioning di macchine, macchine virtuali o container, installa un runtime e un database e li opera. Massimo controllo, massima responsabilità: capacità, applicazione delle patch, disponibilità e turni di reperibilità restano in mano a chi sviluppa.

Gli argomenti classici a favore valgono ancora – un solo posto che condivide i dati fra più applicazioni, integrazioni dirette, un unico punto di accesso da mettere in sicurezza – e la forma interna può essere un monolite o dei microservizi; il modello operativo è lo stesso.

Backend serverless. Un provider fa girare l’infrastruttura e fattura a consumo. Due varianti: Function as a Service, dove si distribuisce codice personalizzato come funzioni che scalano da zero, e Backend as a Service, dove database, autenticazione, API, archiviazione e funzioni arrivano come piattaforma gestita.

Il guadagno è la velocità – nessun server da costruire prima della prima feature – e il prezzo è il controllo sui livelli più bassi. L’intera scala dei modelli di hosting è confrontata in IaaS vs. PaaS vs. BaaS vs. FaaS.

Backend decentralizzati. Nessun operatore unico; lo stato vive su una rete peer-to-peer, di solito open source, come nelle blockchain e nell’archiviazione indirizzata per contenuto. Bitcoin ed Ethereum sono gli esempi canonici, e il frontend di un’app del genere è spesso ospitato allo stesso modo, su reti come IPFS o Swarm anziché su un server.

Resistenza alla censura e nessun punto di controllo centrale, al costo di latenza, throughput e di un modello di programmazione molto diverso. Una nicchia con usi reali, non un sostituto generico degli altri due.

Basato su server vs. serverless vs. BaaS vs. decentralizzato

Casi d’uso tipici

• App mobile e web – account, dati che sopravvivono alla sessione e sincronizzazione fra dispositivi hanno tutti bisogno di un lato server.
• Prodotti multiutente – tutto ciò in cui l’azione di un utente deve essere vista da un altro: collaborazione, marketplace, chat.
• Pagamenti e operazioni sensibili – segreti e denaro non appartengono mai al dispositivo; il backend custodisce le chiavi e parla con i provider.
• Integrazioni e automazione – webhook, job pianificati e pipeline che girano a prescindere dal fatto che un utente sia online o no.
• Funzionalità IA – chiamate ai modelli, retrieval ed esecuzione di tool girano lato server, dove le chiavi restano private e i risultati si possono mettere in cache e verificare.

Quale approccio al backend scegliere? Matrice decisionale

Limiti e trade-off

• Il backend è dove gli errori diventano un problema di tutti. Un bug nel frontend rompe una schermata; un bug nel backend corrompe i dati o li espone. Validazione, permessi e test pesano qui più che in qualsiasi altra parte della codebase.
• L’operatività non sparisce mai – si sposta. Le piattaforme gestite assorbono server, scalabilità e backup, ma qualcuno resta responsabile del modello di dati, delle regole di accesso e del budget. Conviene scegliere un modello in base alle responsabilità che si vogliono tenere, non a quelle che si vogliono dimenticare.
• Controllo e velocità tirano in direzioni opposte. Più stack si gestisce in proprio, più si può personalizzare e più tutto richiede tempo; meno se ne gestisce, più in fretta si rilascia e più si dipende dalla roadmap e dai prezzi di un provider.
• La rete fa parte del contratto. Ogni chiamata dal frontend al backend può essere lenta, fallire a metà o arrivare due volte; budget di latenza, ritentativi e idempotenza sono questioni di backend fin dal primo endpoint.
• “Serverless” ha ancora dei server. Cold start, limiti di esecuzione e fatturazione a consumo sono vincoli reali; sono semplicemente le macchine di qualcun altro, con una curva di costo diversa.

Il backend 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.

Mappato sui livelli descritti sopra: il livello dati e il livello API vengono generati dal modello di dati, autenticazione e permessi di classe stabiliscono chi può fare che cosa su ogni richiesta, Cloud Code contiene la logica di business e i job in background specifici del prodotto, e il livello infrastrutturale – hosting, scalabilità, backup, monitoring – è compito della piattaforma.

La richiesta sezionata in cima a questa pagina è il vero formato che Back4app scambia sulla rete, e gli SDK che l’hanno inviata sono il modo in cui il frontend parla con quel backend da ogni piattaforma principale.