Laravel: la scelta migliore per le applicazioni Web-based
"Laravel è la scelta migliore" è il tipo di affermazione di cui diffido, perché nessuno strumento è il migliore per tutto. Eppure, quando un cliente mi chiede su cosa costruire una nuova applicazione web aziendale, nella maggioranza dei casi la mia risposta è Laravel, e non per moda: è una scelta di ingegneria, fondata su velocità di sviluppo, manutenibilità ed ecosistema. Vediamo perché lo scelgo, cosa lo distingue nel 2026, e quando invece consiglio altro. Continua a leggere
Ultima modifica:
OPcache è la singola ottimizzazione PHP con il maggiore impatto sulle prestazioni: su una applicazione Laravel media, la configurazione corretta riduce il tempo di risposta del 40-60%. Ma la configurazione di default non è ottimale per la produzione. Vi mostro i parametri che cambio sempre e perché. 
Un e-commerce B2B con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
I worker Laravel Horizon di un cliente consumavano 500MB di RAM dopo 6 ore di esecuzione e venivano killati automaticamente. Il memory leak non era ovvio: un event listener registrato globalmente teneva riferimenti a ogni job processato. Vi mostro il processo di diagnosi con Blackfire e le strategie di correzione. 
La sessione PHP è uno dei vettori di attacco più sottovalutati. In un assessment su un portale bancario PHP, ho dimostrato session fixation in meno di 10 minuti sfruttando un PHPSESSID passato in query string. Vi mostro la configurazione php.ini che elimina la classe di vulnerabilità e i pattern di sessione sicura per Laravel. 
PHP 8.4 introduce lazy objects nativi che permettono di ritardare l'inizializzazione di servizi pesanti fino al primo utilizzo, senza proxy manuali. Ho testato l'impatto su un'applicazione Symfony con 80 servizi registrati nel container: il tempo di bootstrap dell'applicazione è sceso del 35% con 8 righe di configurazione. 
Ogni codebase PHP legacy che eredo ha la stessa peste: costanti integer o stringhe magiche per rappresentare stati di business. ORDINE_STATO_1, ORDINE_STATO_2. Con PHP 8 Enums, ho modernizzato un sistema ordini trasformando 40 costanti sparse in enum tipizzati con metodi di dominio. Il codice è diventato leggibile. 
La dependency injection è il pattern che più di ogni altro determina la testabilità del codice PHP. Vi mostro i pattern avanzati che uso in progetti complessi: constructor promotion di PHP 8, binding a interfaccia, lazy proxy per servizi costosi e come scrivere test che non dipendono dall'implementazione concreta. 
La vecchia ricetta della "classe di sicurezza" che ripulisce GET e POST all'ingresso non protegge più nulla: è un anti-pattern che dà falsa sicurezza. La doctrine corretta nel 2026 è netta: si valida l'input al confine con una logica di allowlist e si escapa l'output in base al contesto in cui finisce. Vediamo come si fa davvero, con filter_var, prepared statement, htmlspecialchars e una Content Security Policy. 
Modernizzare un'applicazione PHP 7.4 a PHP 8.3 non significa riscrivere tutto - significa sfruttare le nuove feature dove migliorano la leggibilità e la sicurezza. Vi mostro il processo che uso: identificare i candidati giusti per match expression e named arguments, refactoring sicuro con test a tappeto.