Cos'è un'app full-stack? Una spiegazione in parole semplici

Un'app full-stack è un'app che include tutti i livelli necessari per funzionare: il frontend che le persone vedono e toccano, il backend che gira su un server e applica le regole, e il database che ricorda tutto. Una lista di cose da fare che salva i tuoi compiti, ti permette di accedere da qualsiasi dispositivo e non mostra la tua lista a nessun altro è full-stack. Una singola pagina che mostra solo i tuoi orari di apertura non lo è.

"Stack" significa semplicemente i livelli di tecnologia impilati uno sull'altro. "Full" significa che ci sono tutti.

Perché è importante quando crei con l'AI

Quando descrivi un'app a un creatore con l'AI, le parole che usi decidono quali livelli costruisce. "Crea una pagina che mostri il nostro menu" produce un frontend. "Permetti ai clienti di ordinare dal nostro menu e fai vedere alla cucina i nuovi ordini" richiede tutti e tre i livelli, perché gli ordini devono essere salvati, condivisi tra due tipi di utenti e tenuti privati.

Conoscere la differenza ti aiuta in tre modi:

• Chiedi la cosa giusta. Se vuoi che i dati vengano salvati, dillo. Un creatore che costruisce solo il frontend sembrerà finito ma dimenticherà tutto al refresh.
• Riconosci la finta completezza. Una demo con dati di esempio può sembrare identica a un'app funzionante. Conoscere i livelli ti permette di verificare che i dati vadano davvero da qualche parte.
• Capisci i costi di esecuzione. Un solo frontend può essere servito come file statici. Un backend e un database sono programmi che girano su server, ed è lì che si concentra gran parte del costo di hosting.

Un'analogia di tutti i giorni: un ristorante

Pensa a un ristorante.

• La sala è il frontend. Menu, tavoli e il taccuino del cameriere. È ciò che vedono gli ospiti, e dovrebbe essere piacevole e facile da usare.
• La cucina è il backend. Gli ospiti non vi entrano mai. Riceve gli ordini, controlla che il piatto sia disponibile, lo cucina e rifiuta richieste assurde. Qui vivono le regole.
• La dispensa e il registro degli ordini sono il database. Contengono ciò che esiste e ciò che è stato ordinato, così nulla va perso al cambio di turno.

Un ristorante con solo la sala può mostrarti un bel menu, ma non ti sfama. Questa è un'app solo frontend che finge di essere full-stack.

I tre livelli nel dettaglio

I livelli comunicano tra loro in un ordine fisso. Il frontend chiede qualcosa al backend tramite un'API — un insieme definito di richieste che il backend accetta. Il backend verifica la richiesta, legge o scrive nel database e restituisce una risposta. Il frontend non parla mai direttamente con il database.

Questo ordine è l'idea di sicurezza più importante di tutto lo stack. Tutto ciò che è nel frontend può essere letto e modificato dal visitatore, perché gira sul suo dispositivo. Quindi le regole — "solo il proprietario può vedere questa fattura", "un coupon può essere usato una sola volta" — devono essere applicate nel backend. Per saperne di più sulla divisione, vedi frontend vs backend.

Un esempio pratico: un'app per prenotare lezioni

Supponi di gestire uno studio di yoga e di voler far prenotare le lezioni online.

Cosa fa il visitatore: apre il sito, vede le lezioni di questa settimana, ne tocca una, accede e prenota un posto.

Cosa succede sotto:

1. Il frontend mostra il calendario. Per riempirlo, chiede al backend: "Quali lezioni ci sono questa settimana e quanti posti restano?"
2. Il backend chiede al database le lezioni e conta le prenotazioni per ognuna, poi risponde.
3. Il visitatore tocca Prenota. Il frontend invia "prenota la lezione 42 per questa persona autenticata".
4. Il backend verifica: questa persona è davvero autenticata? La lezione è piena? L'ha già prenotata? Solo se tutto è in ordine scrive una nuova riga di prenotazione nel database.
5. Il backend risponde "prenotato" e il frontend mostra una conferma.
6. Più tardi, la proprietaria dello studio accede e vede l'elenco delle lezioni. Il backend verifica che sia un'amministratrice prima di mostrare i nomi di tutti.

Ora immagina che fosse costruito solo come frontend. Il calendario potrebbe apparire, e il pulsante Prenota potrebbe mostrare una bella spunta, ma la prenotazione scomparirebbe al refresh, il conteggio dei "posti rimasti" sarebbe sbagliato per tutti gli altri e la proprietaria non la vedrebbe mai. Il passaggio 4 — i controlli — mancherebbe del tutto. È questa la differenza pratica.

Termini chiave

• Frontend (lato client): la parte che gira nel browser.
• Backend (lato server): la parte che gira su un server. Chiamato anche server API.
• Database: dove i dati sono conservati in modo organizzato. Vedi cos'è un database.
• API: l'elenco delle richieste che il backend accetta dal frontend o da altri programmi.
• Autenticazione: verificare chi è una persona (accesso). Autorizzazione: verificare cosa può fare.
• Deployment: mettere tutti i livelli su server perché il pubblico possa usarli.
• Monolite vs servizi: un unico programma che fa tutto, oppure più programmi più piccoli (per esempio un sito e un'API separata). Entrambi sono full-stack.

Errori comuni e idee sbagliate

• "Sembra finito, quindi è finito." I dati di esempio e un pulsante che sembra funzionare non sono dati salvati. Aggiorna la pagina, aprila in una finestra privata e controlla che i dati siano ancora lì.
• Mettere le regole nel frontend. Nascondere un pulsante non è sicurezza. Se il backend non controlla, chiunque conosca la richiesta può inviarla.
• Mettere le chiavi segrete nel frontend. Una chiave di un fornitore di pagamenti o di AI nel codice del browser è leggibile da ogni visitatore. Le chiavi appartengono al backend, nelle variabili d'ambiente — vedi variabili d'ambiente e segreti.
• Pensare che full-stack significhi complicato. Una piccola app full-stack può essere composta da qualche schermata, qualche route nel backend e tre tabelle nel database. È una descrizione dei livelli, non della dimensione.
• Pensare di dover scegliere da solo ogni tecnologia. Qualsiasi stack sensato e diffuso va bene per una prima versione. Conta di più una descrizione chiara dei dati e delle regole.

Cosa chiedere al tuo creatore di app con l'AI

Descrivi l'app in termini dei tre livelli, anche se non li nomini:

• I dati: "Salva le lezioni (nome, orario, capienza) e le prenotazioni (lezione, persona, orario di prenotazione) in un database."
• Le regole: "Non si può prenotare una lezione oltre la capienza. Una persona può prenotare una lezione una sola volta. Solo gli amministratori possono vedere chi ha prenotato."
• Le schermate: "Un calendario settimanale, una conferma di prenotazione, una pagina di amministrazione con le prenotazioni per lezione."
• I controlli: "Applica queste regole sul server, non solo nella pagina. Tieni le chiavi API sul server."

Poi testa con spirito critico: aggiorna la pagina, accedi con due persone diverse, prova a vedere dati che non dovresti vedere. La guida alla creazione di un'app con l'AI illustra questo ciclo dall'inizio alla fine.

App full-stack su Mythex

Mythex crea app web full-stack a partire da una descrizione in chat. Per impostazione predefinita una nuova app riceve un frontend in React e TypeScript; quando l'app deve salvare dati, Mythex aggiunge al progetto un database Postgres dedicato, e puoi chiedere un server API separato (per esempio in Python, Node, C# o Java) accanto al sito. Tutto gira insieme in un'anteprima dal vivo e viene pubblicato su un URL pubblico. La pagina della documentazione sulle app multi-servizio mostra come un sito e un'API vengono visualizzati in anteprima e pubblicati insieme, e la pagina del costruttore di app full-stack offre punti di partenza.

Domande