Cos'è un server? Una guida in parole semplici per chi crea app

Un server è un computer — o un programma che gira su un computer — che attende richieste e le risponde. Quando apri un sito web, il tuo browser (il client) invia una richiesta attraverso internet, e un server da qualche parte rimanda la pagina, le immagini o i dati. Ogni app che usi, dalla posta elettronica all'home banking, dipende da server che fanno questo milioni di volte al giorno.

Perché i server contano quando crei con l'AI

Quando un creatore con l'AI ti realizza un'app, una parte del codice gira nel browser del visitatore e una parte di solito gira su un server. La parte sul server fa le cose che il browser non può gestire in modo affidabile o non può fare da solo:

• Salvare e caricare dati da un database.
• Custodire i segreti, come le chiavi API di pagamento o dei fornitori di AI, che non devono mai arrivare al browser.
• Verificare i permessi — assicurarsi che un utente possa vedere e modificare solo i propri record.
• Parlare con altri servizi: addebitare una carta, inviare un'email, chiamare un modello di AI.

Sapere cosa fa il server ti aiuta a capire dove vivono davvero le regole della tua app, perché alcune modifiche richiedono una nuova pubblicazione e cosa paghi quando ospiti un'app. Per la divisione tra le due parti, vedi frontend vs backend.

Un'analogia di tutti i giorni

Un server è come il personale allo sportello di un ufficio postale. Non va in giro a cercare clienti; aspetta. Un cliente (il client) si presenta con una richiesta — "spedisci questo pacco", "c'è posta per me?" — l'impiegato la gestisce e restituisce un risultato. Un solo sportellista può servire molti clienti uno dopo l'altro, e un ufficio affollato apre più sportelli.

L'ufficio postale ha anche regole che il cliente non può aggirare: devi mostrare un documento per ritirare un pacco. È il compito del server anche in un'app — il browser può chiedere qualsiasi cosa, ma il server decide cosa ottiene.

Come una richiesta raggiunge un server

Quando qualcuno visita https://bookings.example.com/schedule:

1. Ricerca DNS. Il browser chiede al sistema dei nomi di dominio a quale indirizzo IP punti bookings.example.com. Vedi come funzionano i domini e il DNS.
2. Connessione. Il browser si connette a quell'indirizzo, sulla porta 443 per HTTPS, e stabilisce una connessione cifrata. Vedi cos'è HTTPS.
3. Richiesta. Invia una richiesta HTTP: GET /schedule.
4. Lavoro. Il server esegue il codice che gestisce /schedule — magari cerca le prenotazioni di oggi nel database.
5. Risposta. Rimanda un codice di stato (200 OK) e il contenuto — una pagina HTML, o dati JSON che la pagina mostrerà.

Tutto questo di solito richiede una frazione di secondo.

Tipi di server di cui sentirai parlare

Nota che "server" indica sia la macchina sia il programma. "Il server è andato in crash" può significare entrambe le cose.

Un esempio pratico: un'app di prenotazioni per un salone

Ecco cosa fa il server in una piccola app di prenotazioni per un salone:

• Un visitatore apre il sito. Il server (o una CDN davanti ad esso) invia i file della pagina.
• La pagina chiede al server GET /api/slots?date=2026-10-03. Il server interroga il database per gli slot liberi e li restituisce come JSON.
• Il visitatore prenota le 14:00. La pagina invia POST /api/bookings. Il server verifica che lo slot sia ancora libero — non si fida della parola del browser — salva la prenotazione e restituisce 201 Created.
• Il server chiama un servizio email con una chiave segreta, conservata sul server, per inviare una conferma.

Se spegnessi il server, la pagina potrebbe ancora caricarsi da una CDN, ma non potrebbe mostrare slot né salvare prenotazioni.

Cosa serve a un server per funzionare bene

• Memoria (RAM) e CPU. Con troppa poca memoria l'app va in crash sotto carico; con troppo poca CPU rallenta.
• Essere in esecuzione. Un server spento non può rispondere. Alcune piattaforme mettono in stop le app inattive e le risvegliano alla visita successiva, il che fa risparmiare denaro ma può rendere più lenta la prima richiesta.
• Configurazione e segreti, forniti come variabili d'ambiente.
• Log — il registro di cosa è successo sul server, che è il primo posto dove guardare quando qualcosa si rompe.
• Aggiornamenti e patch di sicurezza, che l'hosting gestito fa per te.

Idee sbagliate comuni

• "Il cloud significa niente server." Il cloud sono i server di altre aziende, affittati a ore o in base all'uso.
• "Un server è un computer grosso e speciale." Qualsiasi computer può fare da server. Il tuo portatile ne fa uno quando apri localhost durante lo sviluppo.
• "Se il pulsante è nascosto, gli utenti non possono usarlo." Chiunque può inviare richieste direttamente al tuo server. I controlli sui permessi devono avvenire sul server, non solo nella pagina.
• "Più server risolvono la lentezza." Spesso la causa vera è una query lenta sul database o un'API esterna. Trova prima il collo di bottiglia.
• "Per avere un'app devo gestire un server." Le piattaforme gestite fanno girare i server per te; tu distribuisci il codice e loro gestiscono le macchine.

Cosa chiedere al tuo creatore con l'AI

• "Quali parti di questa app girano sul server e quali nel browser?"
• "Tieni tutte le chiavi API sul server e leggile dalle variabili d'ambiente."
• "Verifica i permessi sul server per ogni richiesta che legge o modifica dati."
• "Dove trovo i log del server, e cosa dicono su questo errore?"
• "Questa app ha davvero bisogno di un server, o può essere un sito statico?"
• "Cosa succede alla prima richiesta dopo che l'app è stata inattiva?"

I server su Mythex

Su Mythex non configuri né gestisci server. Mentre crei, la tua app gira in un sandbox cloud privato per l'anteprima dal vivo. Quando pubblichi, Mythex la distribuisce — i front end statici come siti statici, i backend (Node, Python, C#, Java e altri) come container costruiti da un Dockerfile — senza nessun hosting da configurare tu. Mythex sceglie la dimensione della macchina al momento del deployment: per impostazione predefinita 1 CPU e 512 MB di memoria, con altre opzioni disponibili su richiesta (fino a 1 GB nel piano Free, e fino a 2 CPU, 4 GB e 3 macchine nel piano Pro). Le app pubblicate vanno in stop quando sono inattive e si risvegliano alla visita successiva, e un'app in stop non consuma nulla in termini di calcolo. I dettagli sono nella documentazione sui backend API e sui limiti di hosting, e la nostra guida all'hosting web copre il quadro più ampio.

Domande