--- title: "Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione" description: "Aggiornare da Laravel 10 a 12 non richiede la migrazione alla struttura slim, ma adottarla elimina Kernel, Provider e boilerplate. Ecco come farlo in sicurezza." canonical: "https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html" author: "Maurizio Fonte" date: "2025-02-13T11:18:24+01:00" modified: "2026-04-14T17:48:55+02:00" section: "Architettura Software" tags: ["Architettura Software", "Refactoring"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) # [Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione](https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html) Giovedì 13 Febbraio 2025, alle 11:18 ![Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione](https://www.mauriziofonte.it/image/001350200-refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.jpg) In un progetto per un'azienda del settore servizi digitali, l'applicativo Laravel 10 che gestiva il backend di una piattaforma SaaS aveva accumulato nel tempo una configurazione frammentata tra sei file: `Http/Kernel.php` con 14 middleware custom, `Console/Kernel.php` con 8 task schedulati, `RouteServiceProvider` con rate limiter personalizzati, `AuthServiceProvider` con 12 policy registrate manualmente, `EventServiceProvider` con 20 listener, e un `AppServiceProvider` che era diventato un contenitore di logica di bootstrap non categorizzabile. L'aggiornamento a Laravel 12 ha funzionato senza toccare la struttura - Laravel 12 supporta pienamente l'architettura di Laravel 10 - ma la migrazione volontaria alla struttura slim introdotta con [Laravel 11](https://laravel.com/docs/11.x/releases) ha ridotto quei sei file a uno solo (`bootstrap/app.php`) più `AppServiceProvider`, eliminando circa 400 righe di boilerplate. ## È necessario adottare la struttura slim quando si aggiorna da Laravel 10? No. La [guida di upgrade a Laravel 12](https://laravel.com/docs/12.x/upgrade) conferma esplicitamente che l'architettura applicativa di Laravel 10 è pienamente supportata: `Http/Kernel.php`, `Console/Kernel.php` e i Service Provider continuano a funzionare senza modifiche. Laravel 12, rilasciato il 24 febbraio 2025, è descritto come "maintenance release" - le novità principali sono starter kit aggiornati e l'aggiornamento delle dipendenze (Carbon 3, PHPUnit 11). La struttura slim è una scelta architetturale, non un requisito di upgrade. Detto questo, la migrazione ha senso quando la frammentazione della configurazione è diventata un problema reale: nuovi sviluppatori che impiegano ore per capire dove sono registrati middleware e route, logica di bootstrap sparsa in più Provider che nessuno ricorda di manutenere, e test che richiedono mock elaborati dei Kernel per simulare configurazioni diverse. La struttura slim risolve questi problemi centralizzando routing, middleware ed eccezioni in un unico file con un'API fluente. ## Il nuovo bootstrap/app.php: tutto in un unico punto Il cuore della struttura slim è `bootstrap/app.php`, che usa `Application::configure()` con tre callback - `withRouting`, `withMiddleware`, `withExceptions` - per sostituire `Http/Kernel.php`, `Console/Kernel.php`, `RouteServiceProvider` e `Exceptions/Handler.php`: ```php use Illuminate\Foundation\Application; use Illuminate\Foundation\Configuration\Exceptions; use Illuminate\Foundation\Configuration\Middleware; use Illuminate\Cache\RateLimiting\Limit; use Illuminate\Http\Request; use Illuminate\Support\Facades\RateLimiter; return Application::configure(basePath: dirname(__DIR__)) ->withRouting( web: __DIR__.'/../routes/web.php', api: __DIR__.'/../routes/api.php', commands: __DIR__.'/../routes/console.php', health: '/up', then: function () { RateLimiter::for('api', function (Request $request) { return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip()); }); }, ) ->withMiddleware(function (Middleware $middleware) { $middleware->alias([ 'is_admin' => \App\Http\Middleware\EnsureUserIsAdmin::class, 'locale' => \App\Http\Middleware\SetLocale::class, ]); }) ->withExceptions(function (Exceptions $exceptions) { $exceptions->render(function (\Symfony\Component\HttpKernel\Exception\NotFoundHttpException $e, Request $request) { if ($request->is('api/*')) { return response()->json(['message' => 'Risorsa non trovata.'], 404); } }); }) ->create(); ``` Quello che prima richiedeva `Http/Kernel.php` (middleware globali, gruppi, alias), `RouteServiceProvider` (caricamento rotte, rate limiter) e `Exceptions/Handler.php` (rendering custom) è ora in un unico file con un'API dichiarativa. Laravel 11+ gestisce internamente i [middleware](https://laravel.com/docs/12.x/middleware) del gruppo `web` (EncryptCookies, StartSession, VerifyCsrfToken) - nel nuovo `withMiddleware` vanno registrati solo i middleware custom dell'applicativo. ## La migrazione pratica: eliminare i file obsoleti La migrazione segue un ordine preciso per evitare rotture. Primo: creare il nuovo `bootstrap/app.php` con la configurazione migrata da Kernel e Provider, senza eliminare ancora i vecchi file. Secondo: verificare che l'applicativo funzioni con entrambe le configurazioni presenti (Laravel privilegia `bootstrap/app.php` se usa la nuova struttura). Terzo: eliminare i file obsoleti uno alla volta - `Http/Kernel.php`, `Console/Kernel.php`, `RouteServiceProvider`, `AuthServiceProvider` (se le policy seguono le convenzioni di naming, l'autodiscovery le registra automaticamente), `EventServiceProvider` (l'event discovery è attivo di default). Per applicativi di medie dimensioni, [Laravel Shift](https://laravelshift.com/) automatizza la maggior parte della migrazione strutturale generando un PR con le modifiche necessarie - inclusa la conversione dei Kernel, la migrazione dei Provider e l'aggiornamento delle dipendenze. Il costo ($39 per lo shift L10→L11) è spesso inferiore al tempo che richiederebbe una migrazione manuale su un codebase con logica custom nei Kernel. Due attenzioni: il file `routes/api.php` non è più incluso di default in Laravel 11+ - se l'applicativo lo usa, va specificato esplicitamente in `withRouting` o installato con `php artisan install:api`. E il file `routes/console.php` cambia ruolo: da file caricato dal `Console/Kernel` a file che usa la facade `Schedule` direttamente per definire i task schedulati. ## Errori comuni nella migrazione strutturale Il primo errore è migrare la struttura durante l'upgrade di versione. Sono due operazioni distinte: prima aggiorna a Laravel 12 mantenendo la struttura di Laravel 10 (la guida ufficiale stima 5 minuti), verifica che tutto funzioni, poi migra alla struttura slim come operazione separata. Mescolare le due operazioni rende impossibile isolare la causa di eventuali regressioni. Il secondo è dimenticare middleware registrati in `Http/Kernel.php` che non hanno equivalente nella configurazione interna di Laravel 11+. I middleware standard del gruppo `web` (cookies, sessioni, CSRF) sono gestiti internamente, ma qualsiasi middleware custom - rate limiter specifici, middleware di tenant isolation, middleware di locale - deve essere esplicitamente migrato in `withMiddleware`. Un `grep -r 'middleware' app/Http/Kernel.php` prima della rimozione è il check minimo. Il terzo è eliminare i Service Provider senza verificare che l'autodiscovery copra le registrazioni. Le policy vengono scoperte automaticamente solo se seguono la convenzione `App\Policies\ModelPolicy` - policy con nomi non convenzionali devono essere registrate esplicitamente in `AppServiceProvider` tramite `Gate::policy()`. Lo stesso vale per gli event listener: l'event discovery funziona solo con listener type-hinted nell'argomento del metodo `handle`. I [test automatici](https://www.mauriziofonte.it/blog/post/test-automatici-codebase-php-legacy-senza-riscrittura.html) sono la rete di sicurezza indispensabile per questa migrazione - senza di essi, l'unico modo di verificare che nessun middleware o provider sia stato perso è testare manualmente ogni rotta dell'applicativo. L'[aggiornamento da versioni legacy di Laravel e Symfony](https://www.mauriziofonte.it/blog/post/aggiornamento-applicazioni-php-legacy-symfony-3-4-7-laravel-5-8-11-12-sicurezza-performance-pmi.html) copre il percorso completo per applicativi che partono da versioni più datate (Laravel 5-9), dove la distanza strutturale è significativamente maggiore. Per conoscere il mio approccio alla modernizzazione di applicativi Laravel, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se il tuo applicativo Laravel 10 necessita di un aggiornamento strutturale e vuoi pianificare la migrazione senza rischi, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'analisi della configurazione attuale e dalla copertura dei test. Dall'articolo al lavoro vero Se il codice di cui parla questo articolo è il tuo Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione. [Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteFeature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L1212 Febbraio 2025](https://www.mauriziofonte.it/blog/post/feature-flag-laravel-pennant-custom-l9-l10-laravel-12-refactoring.html)[Articolo successivo »Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa14 Febbraio 2025](https://www.mauriziofonte.it/blog/post/laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.html) ### Articoli correlati a Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione - [Middleware Laravel 12: da Kernel.php a bootstrap/app.php con security headers, rate limiting e terminable middleware](https://www.mauriziofonte.it/blog/post/laravel-12-middleware-avanzati-sicurezza-logica-business-pmi-refactoring.html) Il middleware HTTP implementa il Chain of Responsibility pattern GoF, 1994 e PSR 15 PHP FIG, 2018 lo ha standardizzato. Laravel 11 PR 6188 ha · 13 Marzo 2025 ![Middleware Laravel 12: da Kernel.php a bootstrap/app.php con security headers, rate limiting e terminable middleware](https://www.mauriziofonte.it/image/001540070-laravel-12-middleware-avanzati-sicurezza-logica-business-pmi-refactoring.jpg) - [Gestione errori API Laravel 12: da stack trace in produzione a Problem Details RFC 9457 con renderable exceptions](https://www.mauriziofonte.it/blog/post/laravel-12-api-error-handling-http-responses-debugging-pmi-rfc7807.html) RFC 9457 luglio 2023, IETF Standards Track ha sostituito RFC 7807 come standard per i dettagli di errore nelle API HTTP, definendo il media type · 14 Marzo 2025 ![Gestione errori API Laravel 12: da stack trace in produzione a Problem Details RFC 9457 con renderable exceptions](https://www.mauriziofonte.it/image/001550070-laravel-12-api-error-handling-http-responses-debugging-pmi-rfc7807.jpg) - [Context7 e la fine delle allucinazioni di versione: docs in-context per Laravel 13 e Symfony 7.4](https://www.mauriziofonte.it/blog/post/context7-allucinazioni-versione-docs-in-context-laravel-symfony.html) Un LLM addestrato su documentazione datata genera codice per la versione sbagliata del framework: è la classica allucinazione di versione. Context7 · 24 Agosto 2026 ![Context7 e la fine delle allucinazioni di versione: docs in-context per Laravel 13 e Symfony 7.4](https://www.mauriziofonte.it/image/005140070-context7-allucinazioni-versione-docs-in-context-laravel-symfony.jpg) - [Rate limiting avanzato in Laravel 12: proteggere API e form da abusi](https://www.mauriziofonte.it/blog/post/rate-limiting-avanzato-laravel-12-protezione-api-form-abusi.html) Un endpoint di ricerca senza throttling è un invito: nel mio lavoro su API Laravel ad alto traffico ho visto scraper distribuiti saturare i worker · 11 Giugno 2026 ![Rate limiting avanzato in Laravel 12: proteggere API e form da abusi](https://www.mauriziofonte.it/image/004710070-rate-limiting-avanzato-laravel-12-protezione-api-form-abusi.jpg) - [Health check applicativi Laravel 12: da controller custom a Health Routing con DiagnosingHealth e spatie/laravel-health](https://www.mauriziofonte.it/blog/post/monitoraggio-proattivo-laravel-health-routing-l12-refactoring.html) L'Health Routing di Laravel, introdotto in Laravel 11 PR 47309 , espone un endpoint /up che dispatcha l'evento DiagnosingHealth i listener che · 10 Marzo 2025 ![Health check applicativi Laravel 12: da controller custom a Health Routing con DiagnosingHealth e spatie/laravel-health](https://www.mauriziofonte.it/image/001510070-monitoraggio-proattivo-laravel-health-routing-l12-refactoring.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html Pubblicato: 2025-02-13 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.