"Separiamo backend e frontend così le API sono riusabili." Questa frase, in molti progetti, porta a costi di sviluppo molto più alti del necessario. Perché nella teoria suona perfetta — architettura pulita, disaccoppiamento, flessibilità futura. Nella pratica? API progettate di fretta per servire un solo frontend, documentazione assente o incompleta, e un costo di sviluppo che è molto più alto di quello che sarebbe stato necessario.
Se stai avviando un progetto e qualcuno ti propone di separare backend e frontend "per il futuro", fermati. Quel futuro spesso non arriva nei tempi immaginati — e intanto stai pagando oggi per una flessibilità che potresti non usare.
Perché si separa backend e frontend
La promessa della riusabilità
Il ragionamento è questo: costruisci un backend con API REST (o GraphQL), e poi qualsiasi frontend può consumarle. Vuoi un'app mobile? Collegala alle stesse API. Un partner vuole integrarsi? Le API sono già pronte. Vuoi rifare il frontend con un altro framework? Il backend non cambia.
In teoria è elegante. In pratica, succede qualcos'altro.
La realtà: API frontend-driven senza documentazione
Il team ha poco tempo. Le scadenze sono strette. Quindi le API vengono progettate per il frontend che si sta costruendo, non per un consumatore generico. Ogni endpoint restituisce esattamente i dati che quella specifica vista necessita. Le risposte sono modellate sulla struttura delle pagine, non sulle entità di business.
Risultato: le API difficilmente risultano davvero riusabili. Sono il backend di quel frontend specifico, con un livello di indirezione in più che non aggiunge valore ma aggiunge complessità.
E la documentazione? Spesso è assente o incompleta. Quando tra un anno qualcuno proverà a usare quelle API per un'app mobile, dovrà leggere il codice del frontend per capire cosa fanno gli endpoint.
Quanto costa davvero la separazione
Doppio lavoro su autenticazione e autorizzazione
Con un'applicazione monolitica, l'autenticazione è un problema risolto: sessione server-side, cioè gestita dal server stesso, middleware, e via. Con API separate devi gestire token JWT, cioè credenziali firmate che identificano l’utente, refresh token, CORS, cioè le regole che permettono o bloccano chiamate tra domini diversi, e tutta l'infrastruttura di autenticazione stateless, cioè senza memoria di sessione sul server. È lavoro aggiuntivo che in un monolite spesso non è necessario.
Doppia gestione degli errori
Nel monolite, un errore mostra una pagina di errore. Fine. Con backend e frontend separati, devi progettare un contratto di errore: codici HTTP, formati di risposta, messaggi localizzati, gestione dei timeout, retry logic. E il frontend deve interpretare tutto e mostrare messaggi sensati all'utente.
Ogni caso limite va gestito due volte — una lato backend, una lato frontend. Il tempo di sviluppo aumenta sensibilmente su ogni funzionalità che gestisce errori.
Doppio deploy, doppio ambiente, doppio debugging
Due repository. Due pipeline di CI/CD. Due ambienti di staging. Due set di variabili d'ambiente. Quando qualcosa si rompe in produzione, devi capire se il bug è nel backend, nel frontend, o nel contratto tra i due. Il debugging diventa un'investigazione tra due codebase che parlano attraverso HTTP.
Con un monolite, apri un file, metti un breakpoint, e vedi cosa succede. Con due applicazioni separate, apri due terminali, due debugger, e l’analisi diventa più complessa.
Il costo in termini di team
Spesso servono competenze distinte: sviluppatori backend e sviluppatori frontend. O sviluppatori full-stack che però devono fare context switch continuo tra due mondi. Il risultato è che o hai un team più grande, o hai persone meno efficaci perché spalmano la loro attenzione su due codebase.
Trovare sviluppatori senior è già difficile. Trovarne due tipi diversi per lo stesso progetto è una complessità in più.
L'alternativa: Laravel Inertia e il monolite moderno
Cos'è Laravel Inertia (spiegato semplice)
Laravel Inertia è un approccio che ti dà il meglio dei due mondi: tutta la potenza del backend Laravel, con routing, autenticazione, autorizzazione, ORM, cioè il livello che collega oggetti del codice e tabelle del database, e sessioni, con un frontend moderno in Vue, React o Svelte, senza la necessità di API REST, JWT e configurazioni CORS.
Il frontend e il backend vivono nello stesso progetto. Il backend passa i dati direttamente ai componenti frontend, come se fossero viste server-rendered — ma con tutta l'interattività di una single-page application.
Cosa elimini
Con questo approccio elimini una serie di costi strutturali: non hai bisogno di API REST dedicate perché i dati fluiscono direttamente dal controller Laravel ai componenti Vue o React; non devi costruire un’autenticazione stateless perché usi le sessioni di Laravel, già consolidate; il tema CORS scompare perché si tratta della stessa applicazione; non devi mantenere documentazione API interna per un frontend che vive nello stesso progetto; e naturalmente eviti il doppio deploy, con un solo ambiente da mantenere.
Cosa tieni
Allo stesso tempo tieni ciò che di solito interessa davvero a chi vuole separare. Continui a scrivere un frontend moderno con componenti Vue o React, ottieni l’interattività tipica di una SPA e mantieni una struttura pulita in cui il backend gestisce logica, dati e autorizzazione, mentre il frontend si occupa di presentazione e interazione.
Per chi funziona
Inertia funziona perfettamente per la grande maggioranza dei progetti web: SaaS, dashboard, applicazioni CRUD, portali, e-commerce, piattaforme interne.
Non funziona se hai davvero bisogno di API pubbliche, se il frontend deve funzionare offline, o se hai più client diversi che consumano gli stessi dati. Nella mia esperienza, una minoranza dei progetti rientra in queste eccezioni.
"Ma se poi ci serve l'app mobile?"
Questa è l'obiezione più comune. La risposta ha due parti.
Primo: spesso non si rivela necessario. Molti progetti che separano backend e frontend "per l'app mobile" non costruiranno mai quell'app, oppure lo faranno quando i requisiti saranno molto diversi da quelli di oggi.
Secondo: se ti serve, puoi aggiungerla dopo. Aggiungere un layer API a un monolite esistente è spesso più semplice che costruire tutto separato dall'inizio. La logica di business esiste già. Devi solo esporre degli endpoint progettati per il client reale, non per uno ipotetico.
Il costo di aggiungere API in un secondo momento è spesso inferiore al costo di mantenerle dal giorno zero quando nessuno le usa.
Il vero costo della decisione sbagliata
Facciamo i conti su un progetto medio, per esempio un SaaS con autenticazione, dashboard, gestione dati e qualche integrazione. Con backend e frontend separati devi impostare autenticazione JWT, gestire gli errori su entrambi i lati, configurare e mantenere due pipeline CI/CD, toccare due codebase per quasi ogni feature e affrontare debugging più lento su ogni bug. Con Laravel Inertia, o strumenti simili, usi le sessioni Laravel per l’autenticazione, concentri la gestione errori in un solo punto, fai un solo deploy e in genere ogni feature si traduce in un controller e un componente. La separazione porta quindi molto spesso a costi sensibilmente più alti rispetto a un monolite con Inertia, senza benefici concreti nel breve periodo.
Come prendere la decisione giusta
Prima di separare, conviene chiedersi se oggi esista davvero più di un client che consumerà quelle API, se quelle API verranno documentate e mantenute come un prodotto, se il team ha le competenze per gestire due codebase e se il time-to-market sia critico. Se a queste domande manca un “sì” chiaro, il monolite moderno con Inertia resta spesso la scelta più efficace.
Simone Giusti
Consulente software strategico
