--- term: 'Backend (lato server)' seoTitle: 'Backend: significato, frontend vs backend e architetture' headline: 'Che cos''è un backend? Il lato server di un''applicazione, spiegato' slug: backend category: backend-compute shortDefinition: '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.' relatedTerms: - baas-vs-custom-backend - api - serverless-architecture - backend-sdk - decoupled-architecture - scaling-application-backends contrastsWith: - decoupled-architecture faq: - question: 'Che cosa significa backend?' answer: 'La parte di un''applicazione che gli utenti non vedono mai: il codice lato server, il database e l''infrastruttura che ricevono le richieste dall''interfaccia, applicano le regole di business, leggono e scrivono i dati e restituiscono una risposta. Se il frontend è il cruscotto di un''auto, il backend è il motore e l''impianto di alimentazione – invisibili dal sedile, responsabili di tutto ciò che si muove.' - question: 'Che cos''è un frontend?' answer: 'La parte di un''applicazione che gli utenti vedono e con cui interagiscono: schermate, pulsanti, moduli e navigazione, resi sul loro dispositivo da un browser o da un''app mobile. È il livello di presentazione: raccoglie l''input e mostra i risultati, ma le decisioni e i dati dietro quei risultati vivono nel backend, che il frontend raggiunge attraverso un''API.' - question: 'Qual è la differenza tra frontend e backend?' answer: 'Dove gira il codice e con chi parla. Il frontend gira sul dispositivo dell''utente – browser o app – e disegna le schermate, raccoglie l''input e chiama le API. Il backend gira su server controllati dal team (o da una piattaforma) e possiede i dati, le regole e la sicurezza. I due si incontrano a un''API: il frontend chiede, il backend decide e risponde.' - question: 'Il backend e il server sono la stessa cosa?' answer: 'Non esattamente. Un server è una macchina o un processo che risponde a richieste di rete; il backend è l''intero sistema dietro l''interfaccia – codice applicativo, database, autenticazione, job in background e i server su cui girano. Un solo backend può estendersi su molti server, e nelle architetture serverless il "server" si affitta al millisecondo e non si gestisce mai direttamente.' - question: 'Quali sono i tipi di backend?' answer: 'Raggruppati in base a chi fa girare i server: backend basati su server, dove il team esegue il provisioning di macchine o container e li opera; backend serverless, dove un provider gestisce l''infrastruttura e fattura a consumo – Function as a Service per il codice personalizzato e Backend as a Service per l''intero stack; e backend decentralizzati, dove nessuna parte singola opera il sistema e i peer condividono lo stato su una rete. La maggior parte dei prodotti oggi combina i primi due.' - question: 'Un database è un backend?' answer: 'No – è un componente di un backend, di solito il più importante. Un database archivia e recupera dati; il backend lo avvolge con un''API, validazione, permessi e logica, così che i client non lo tocchino mai direttamente. Una piattaforma che espone un database tramite API generate, con autenticazione e regole di accesso, è un backend; un database nudo non lo è.' - question: 'Che cos''è il Backend as a Service (BaaS)?' answer: 'Un backend gestito che si configura invece di costruirlo: database ospitato, API REST e GraphQL generate automaticamente, autenticazione degli utenti, archiviazione di file, notifiche push e funzioni serverless per la logica personalizzata. Restano da scrivere il frontend e le regole che contano per il prodotto; la piattaforma fa girare il resto. È il modo più rapido per ottenere un backend di produzione per un''app mobile o web.' - question: 'Che cosa fa uno sviluppatore backend?' answer: 'Progetta il modello di dati, costruisce e documenta le API, implementa la logica di business e i job in background, mette in sicurezza autenticazione e permessi e mantiene il sistema veloce e disponibile mentre il traffico cresce. In pratica una quota ampia del lavoro è operatività – deployment, monitoring, scalabilità, backup – ed è esattamente la quota che le piattaforme gestite assorbono.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Introduction to the server side — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction' - name: 'Client-Server overview — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'The Twelve-Factor App' url: 'https://12factor.net/' - name: 'Frontend and backend — Wikipedia' url: 'https://en.wikipedia.org/wiki/Frontend_and_backend' cta: title: 'Un backend di produzione, senza costruirlo' text: 'Back4app dà alla tua app database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni Cloud Code dal primo giorno – l''intero lato server, configurato invece di costruito.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-19' translationKey: backend-meaning --- **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 | Domanda | Risposta | | --- | --- | | La definizione | Tutto ciò che sta dietro l'interfaccia: codice server, database, autenticazione, job, infrastruttura | | Il confine | Un'API – il frontend chiede, il backend valida, decide e risponde | | I livelli | API · logica di business · dati · autenticazione · lavoro in background · infrastruttura | | I modelli di hosting | Basato su server · serverless (FaaS e BaaS) · decentralizzato | | La scelta predefinita nel 2026 | Affittare le parti generiche (database, autenticazione, API); scrivere solo la logica propria | ## 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: ```text 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:** ```javascript // 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 // Flutter / Dart — Back4app Flutter SDK // The frontend asks the backend a question; the backend answers from the database final query = QueryBuilder(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'); ``` **Swift:** ```swift // 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") } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The frontend asks the backend a question; the backend answers from the database val query = ParseQuery.getQuery("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: | | Frontend | Backend | | --- | --- | --- | | Dove gira | Il dispositivo dell'utente: browser, app mobile, desktop | Server controllati dal team o da un provider | | Che cosa possiede | Layout, interazione, stato locale, accessibilità | Dati, regole di business, identità, sicurezza | | Come fallisce | Una schermata rotta per un utente | Dati sbagliati o downtime per tutti gli utenti | | Linguaggi tipici | JavaScript/TypeScript, Swift, Kotlin, Dart | JavaScript/TypeScript, Python, Java, Go, C#, Ruby, PHP, Rust | | Che cosa significa "finito" | Ha l'aspetto e la resa giusti | È corretto, sicuro e ancora veloce sotto carico | | Chi vede il codice | Chiunque – viene distribuito sul dispositivo | Solo il team – non lascia mai il server | 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](/glossary/it/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. ```mermaid flowchart LR accTitle: Frontend, backend e l'API fra loro accDescr: Un frontend sul dispositivo dell'utente invia richieste attraverso un'API al backend, che contiene logica di business, autenticazione e job in background, e dialoga con un database e con servizi esterni prima di restituire una risposta. F["Frontend
(browser, app mobile)"] -->|"richiesta via API"| B["Backend
logica · auth · job"] B --> D[("Database")] B --> S["Servizi esterni
(pagamenti, email, IA)"] B -->|"risposta"| F ``` ## 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](/glossary/it/api-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](/glossary/it/nosql-vs-sql/) e il codice che lo modella, lo interroga e lo migra. - **Autenticazione e autorizzazione** – [chi è il chiamante e che cosa può fare](/glossary/it/autenticazione-vs-autorizzazione/), applicate su ogni richiesta. - **Lavoro in background** – [job e pianificazioni](/glossary/it/job-in-background/) 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à](/glossary/it/scalabilita-del-backend/). 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](/glossary/it/microservizi-vs-monolite/); il modello operativo è lo stesso. **Backend serverless.** Un provider fa girare l'infrastruttura e fattura a consumo. Due varianti: [Function as a Service](/glossary/it/architettura-serverless/), 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](/glossary/it/modelli-di-servizio-cloud/). **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 | Modello | Chi fa girare i server | Che cosa si scrive | Scala per | Ideale per | | --- | --- | --- | --- | --- | | Basato su server | Il proprio team | Tutto: app, livello dati, operatività | Aggiunta di capacità gestita in proprio | Requisiti insoliti, controllo totale, team operativi già esistenti | | Serverless (FaaS) | Il provider | Funzioni e livello dati | Invocazione, da zero | Logica orientata agli eventi, traffico a picchi, team piccoli | | BaaS | Il provider | Solo frontend + logica personalizzata | Consumo, gestito dalla piattaforma | App mobile e web che hanno bisogno in fretta di autenticazione, dati e API | | Decentralizzato | Una rete di peer | Smart contract, client | Crescita della rete | Sistemi a fiducia minima, stato pubblico condiviso | ## 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 | Situazione | Scegliere | | --- | --- | | Un nuovo prodotto mobile o web che ha bisogno di autenticazione, dati e API entro questa settimana | BaaS – configurare l'80 % generico, scrivere il 20 % che è proprio | | Logica orientata agli eventi con traffico a raffiche e nessuna base stabile | Funzioni serverless | | Requisiti stringenti che le piattaforme gestite non riescono a esprimere | Basato su server, con container e un vero piano operativo | | Un sistema il cui intero scopo è che nessuno lo operi | Decentralizzato | | Un backend basato su server già esistente e lento da cambiare | Spostare prima le parti generiche su un [backend gestito](/glossary/it/baas-vs-backend-personalizzato/), tenere il nucleo personalizzato | ## 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](/glossary/it/vendor-lock-in-cloud/) 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](/glossary/it/permessi-di-classe-clp/) stabiliscono chi può fare che cosa su ogni richiesta, [Cloud Code](/glossary/it/cloud-code-funzioni-serverless/) 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](/glossary/it/sdk-backend/) che l'hanno inviata sono il modo in cui il frontend parla con quel backend da ogni piattaforma principale.