"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, middleware, e via. Con API separate devi gestire token JWT, refresh token, CORS, e tutta l'infrastruttura di autenticazione stateless. È 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 (routing, autenticazione, autorizzazione, ORM, 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
- API REST: non servono. I dati fluiscono dal controller Laravel al componente Vue/React direttamente.
- Autenticazione stateless: usi le sessioni di Laravel, consolidate e affidabili.
- CORS: non esiste, è la stessa applicazione.
- Documentazione API: non è necessaria, perché non ci sono API pubbliche.
- Doppio deploy: un solo progetto, un solo deploy, un solo ambiente.
Cosa tieni
- Frontend moderno: scrivi componenti Vue o React come faresti in un'app separata.
- Interattività: le pagine si comportano come una SPA.
- Struttura pulita: il backend gestisce logica, dati e autorizzazione. Il frontend gestisce 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 — un SaaS con autenticazione, dashboard, gestione dati, qualche integrazione:
Con backend e frontend separati:
- Setup autenticazione JWT
- Gestione errori su entrambi i lati
- Due pipeline CI/CD da configurare e mantenere
- Ogni feature richiede modifiche in due codebase
- Debugging più lento su ogni bug
Con Laravel Inertia (o simili):
- Autenticazione: sessioni Laravel
- Gestione errori: un solo punto
- Un deploy
- Ogni feature: un controller, un componente
La separazione può portare a costi sensibilmente più alti rispetto a un monolite con Inertia, senza garantire benefici concreti nel breve periodo.
Come prendere la decisione giusta
Prima di separare, chiediti:
- Abbiamo oggi più di un client che consumerà queste API?
- Le API verranno documentate e mantenute come prodotto?
- Il team ha le competenze per gestire due codebase?
- Il time-to-market è critico?
Se la risposta a queste domande non è un "sì" chiaro, il monolite moderno con Inertia può essere una scelta molto efficace.
Se stai valutando l'architettura del tuo prossimo progetto e vuoi evitare di pagare il doppio per flessibilità che non userai, parliamone. Ti aiuto a scegliere l'approccio giusto per la tua situazione reale, non per scenari ipotetici.
Simone Giusti
Full Stack Developer specializzato in Laravel e Vue.js
