DEV Community: Dev-Iadicola

Symfony 8.1: le novità in arrivo con la release di maggio 2026

Dev-Iadicola — Sun, 20 Sep 2026 17:00:20 +0000

Cosa porta Symfony 8.1 agli sviluppatori PHP

Symfony 8.1 e la prima minor release dopo la major 8.0, prevista per maggio 2026. Come ogni minor release, non introduce breaking changes — l'upgrade dalla 8.0 e trasparente e garantito dalla backward compatibility promise. Continua a richiedere PHP 8.4 e porta miglioramenti incrementali ma significativi su controller, sicurezza, Messenger e i componenti JSON introdotti con la 8.0. Il supporto regolare per la 8.1 dura fino a gennaio 2027.

Le minor release di Symfony sono spesso sottovalutate, ma contengono miglioramenti alla developer experience che hanno un impatto quotidiano sul lavoro degli sviluppatori. Symfony 8.1 non fa eccezione: quasi ogni novità e orientata a ridurre il codice boilerplate nei controller e a dare più controllo sugli strumenti già esistenti.

Novità principali di Symfony 8.1

Controller metadata esposti nel ciclo di vita della richiesta

I metadati del controller — nome della classe, metodo invocato, attributi applicati — sono ora accessibili durante tutto il ciclo di vita della richiesta HTTP, non solo nel controller stesso. Questo apre scenari interessanti per middleware, event listener e logiche trasversali.

Un esempio pratico: un event listener che logga automaticamente quale controller ha gestito ogni richiesta, con quale metodo e quali attributi di sicurezza erano applicati. Prima di Symfony 8.1, ottenere queste informazioni fuori dal controller richiedeva workaround tramite il router o introspezione manuale. Ora sono disponibili come dato di prima classe nell'oggetto request.

Espressioni avanzate in IsGranted

L'attributo #[IsGranted] supporta ora la variabile this nelle espressioni, permettendo di referenziare il controller stesso nelle regole di autorizzazione. Questo e particolarmente utile quando le regole di accesso dipendono dallo stato del controller o da proprieta iniettate nel costruttore.

Consideriamo un controller che gestisce risorse per tenant diversi. Con this nelle espressioni, si può scrivere #[IsGranted(new Expression('this.getCurrentTenant() == subject.getTenant()'))] direttamente sull'azione, senza voter custom dedicati. La logica di autorizzazione resta dichiarativa e visibile nella signature del metodo.

MapRequestHeader: header HTTP come parametri

Il nuovo attributo #[MapRequestHeader] permette di mappare header HTTP direttamente nei parametri del metodo controller. Niente più $request->headers->get('X-Api-Key'): l'header viene iniettato come parametro tipizzato del metodo.

Tipo automatico: il tipo del parametro determina la conversione. Un header mappato a int viene convertito automaticamente.
Validazione integrata: combinabile con constraint di validazione per verificare formato, lunghezza e pattern dell'header.
Valore default: un parametro con valore default rende l'header opzionale. Senza default, un header mancante genera un errore 400.
Naming personalizzabile: il nome dell'header può differire dal nome del parametro, gestendo la convenzione X-Header-Name vs $headerName automaticamente.

Espressioni in MapRequestPayload

#[MapRequestPayload] accetta ora espressioni per i gruppi di validazione dinamici. Questo permette di cambiare le regole di validazione in base al contesto senza logica nel controller. Ad esempio, validare un payload diversamente per utenti admin e utenti normali, o applicare regole diverse in base a un header della richiesta — tutto dichiarato nell'attributo.

Eventi su attributi controller

Symfony 8.1 introduce il dispatch automatico di eventi basati sugli attributi del controller. Applicare un attributo custom a un'azione del controller può automaticamente triggerare un evento, senza codice esplicito nel controller. Questo e potente per cross-cutting concerns come audit logging, rate limiting, feature flags e caching condizionale.

Deprecation e segnali per il futuro

Symfony 8.1 depreca la funzionalita eraseCredentials nel componente Security. Questa funzionalita, presente fin dalle prime versioni di Symfony, cancellava le credenziali sensibili dall'oggetto utente dopo l'autenticazione. La deprecation e un segnale chiaro: verra rimossa in Symfony 9.

Chi usa eraseCredentials() in custom user provider o authenticator ha tempo per adeguarsi durante l'intero ciclo 8.x (fino a novembre 2029 con la LTS 8.4). L'approccio consigliato e spostare la logica di pulizia delle credenziali in un event listener sull'evento di autenticazione.

Miglioramenti a componenti esistenti

Oltre alle novità principali, Symfony 8.1 porta miglioramenti incrementali a diversi componenti.

HttpClient: nuove opzioni per retry e timeout granulari per richiesta.
Cache: supporto migliorato per cache tagging e invalidazione selettiva.
Translation: performance migliorate per cataloghi di traduzione grandi.
Mailer: supporto per nuovi provider di invio email.
Notifier: nuovi canali di notifica e miglioramenti ai canali esistenti.

Conviene aggiornare dalla 8.0 alla 8.1?

Si, senza riserve. L'upgrade da una minor alla successiva in Symfony e sempre sicuro grazie alla backward compatibility promise. Non ci sono breaking changes, solo nuove funzionalita e bugfix. Il processo e semplice: aggiornare le dipendenze in composer.json, eseguire composer update, verificare con la test suite. Per uno sviluppatore freelance PHP, restare sulla minor più recente significa accedere ai bugfix più rapidamente e avere la documentazione più aggiornata come riferimento.

👉 Leggi l'articolo completo su iadicola.it

MapRequestHeader e controller attributes: la DX di Symfony 8.1

Dev-Iadicola — Sat, 19 Sep 2026 21:20:20 +0000

Il problema del boilerplate nei controller Symfony

Ogni controller in un'applicazione Symfony ripete le stesse operazioni: estrarre dati dalla richiesta HTTP, validarli, controllare i permessi, delegare al service layer, costruire la risposta. Gran parte di questo codice e infrastrutturale, non di business — e identico (o quasi) in ogni azione di ogni controller dell'applicazione.

Symfony ha affrontato questo problema progressivamente. Symfony 6.3 ha introdotto #[MapRequestPayload] e #[MapQueryString] per la deserializzazione automatica del body e dei query parameter. Symfony 7 ha aggiunto miglioramenti alla validazione integrata. Symfony 8.1 porta il concetto ancora più avanti con nuovi attributi che coprono gli header HTTP e la logica di autorizzazione.

MapRequestHeader in dettaglio

Il nuovo attributo #[MapRequestHeader] completa la famiglia degli attributi di mapping che Symfony mette a disposizione nei controller. Il suo funzionamento e coerente con gli altri attributi della famiglia: un parametro del metodo controller viene decorato con l'attributo, e Symfony si occupa di estrarre, convertire e validare il dato dalla richiesta HTTP.

Sintassi e utilizzo pratico

L'utilizzo e diretto e intuitivo. Un parametro del metodo controller decorato con #[MapRequestHeader] riceve automaticamente il valore dell'header HTTP corrispondente. Il nome dell'header viene derivato dal nome del parametro, con conversione automatica da camelCase a kebab-case con prefisso standard.

Mapping diretto: #[MapRequestHeader] string $apiKey mappa l'header Api-Key. Niente più $request->headers->get('Api-Key') nel body del metodo.
Nome custom: #[MapRequestHeader(name: 'X-Custom-Token')] string $token permette di specificare il nome esatto dell'header quando non segue la convenzione standard.
Conversione di tipo: il tipo del parametro guida la conversione. int $rateLimit converte automaticamente il valore dell'header in intero. ?string $optional gestisce header assenti.
Array di valori: array $acceptLanguage gestisce header con valori multipli separati da virgola, splittandoli automaticamente in un array.

Validazione degli header

Gli header mappati possono essere validati con gli stessi constraint di validazione usati per qualsiasi altro dato in Symfony. Si possono applicare constraint come #[Assert\NotBlank], #[Assert\Length(max: 255)] o #[Assert\Regex] direttamente sul parametro del controller. Un header che non supera la validazione genera una risposta 400 Bad Request con dettagli sull'errore, senza che il controller debba gestire manualmente la validazione.

Miglioramenti a IsGranted con espressioni

L'attributo #[IsGranted] in Symfony 8.1 guadagna il supporto alla variabile this nelle espressioni. Questo e un cambiamento apparentemente piccolo ma con implicazioni significative per la gestione delle autorizzazioni.

Prima di Symfony 8.1

Per regole di autorizzazione che dipendevano dallo stato del controller (ad esempio, un tenant corrente iniettato nel costruttore), serviva un security voter custom: una classe separata, registrata come servizio, che implementava l'interfaccia VoterInterface. Per logiche semplici, il costo in termini di codice e complessità era sproporzionato rispetto al problema risolto.

Con Symfony 8.1

La variabile this nelle espressioni permette di accedere a metodi e proprieta del controller direttamente nell'espressione di autorizzazione. Pattern comuni come verificare che l'utente appartenga allo stesso tenant della risorsa, o che abbia un ruolo specifico nel contesto dell'organizzazione corrente, si risolvono con un'espressione inline senza classi aggiuntive.

MapRequestPayload con gruppi di validazione dinamici

L'attributo #[MapRequestPayload] in Symfony 8.1 accetta espressioni per i gruppi di validazione. Questo risolve un problema comune: validare lo stesso DTO con regole diverse in contesti diversi.

Validazione per ruolo: un admin può inviare campi che un utente normale non può. I gruppi di validazione dinamici applicano le constraint corrette in base al ruolo, senza logica nel controller.
Validazione per contesto: creazione vs aggiornamento dello stesso oggetto possono avere regole diverse. L'espressione determina il gruppo a runtime.
Validazione per header: combinando con #[MapRequestHeader], si possono applicare regole di validazione diverse in base alla versione dell'API dichiarata nell'header.

Opzioni per dati vuoti in MapQueryString e MapRequestPayload

Symfony 8.1 introduce opzioni dedicate per gestire i casi edge dei dati vuoti. Cosa succede quando un query string e presente ma vuoto? O quando il body della richiesta e un oggetto JSON vuoto? Prima di Symfony 8.1, questi scenari richiedevano gestione manuale. Ora le opzioni acceptEmptyBody e il valore di default per query string vuoti sono configurabili direttamente nell'attributo.

Il pattern emergente: controller come dichiarazione di intenti

Guardando l'evoluzione degli attributi controller da Symfony 6.3 a Symfony 8.1, emerge un pattern chiaro. Il controller sta diventando una dichiarazione di intenti piuttosto che un'implementazione procedurale. Gli attributi descrivono cosa il controller deve ricevere (payload, query, header), come validarlo (constraint, gruppi), chi può accedervi (IsGranted, espressioni) e cosa restituire.

Il framework si occupa dell'esecuzione. Il controller si concentra sull'orchestrazione della business logic. Per chi sviluppa API REST con Symfony, questo approccio riduce drasticamente il codice infrastrutturale e rende i controller più leggibili, testabili e manutenibili. Come sviluppatore freelance PHP, apprezzo particolarmente questo trend perché rende il codice auto-documentante — un nuovo sviluppatore che legge il controller capisce immediatamente cosa fa, senza dover navigare service class e configuration file.

👉 Leggi l'articolo completo su iadicola.it

Messenger e JsonPath in Symfony 8.1: miglioramenti pratici

Dev-Iadicola — Fri, 18 Sep 2026 17:00:10 +0000

Messenger in Symfony 8.1: più controllo sul consumer

Il componente Messenger di Symfony e il cuore della gestione asincrona in qualsiasi applicazione Symfony moderna. Code di messaggi, event-driven architecture, processing in background — tutto passa da Messenger. Symfony 8.1 migliora il comando messenger:consume con nuove opzioni che danno più controllo sul comportamento del worker in ambienti di produzione, dove la stabilita e l'osservabilita sono cruciali.

Nuove opzioni per messenger:consume

Il comando messenger:consume e quello che gira permanentemente sui server di produzione, consumando messaggi dalle code. In Symfony 8.0, le opzioni disponibili coprivano gli scenari base: limite di messaggi, limite di tempo, limite di memoria. Symfony 8.1 aggiunge opzioni per scenari avanzati.

Opzioni di deploy avanzate: configurazione per graceful shutdown durante i deploy, con possibilita di completare il messaggio corrente prima di terminare. Fondamentale per deploy zero-downtime con strumenti come Deployer, Envoyer o Kubernetes rolling updates.
Monitoring granulare: nuove metriche esposte dal worker che permettono di monitorare non solo quanti messaggi vengono processati, ma anche il tempo medio per messaggio, il tasso di errori e la dimensione della coda. Integrabile con strumenti di monitoring come Prometheus, Datadog o New Relic.
Priorità dinamiche: possibilita di cambiare la priorità di consumo tra code diverse senza riavviare il worker, utile in scenari dove il carico varia nel tempo e alcune code devono essere svuotate con priorità durante picchi specifici.

Accesso agli argomenti e opzioni originali del comando

Una novità apparentemente minore ma estremamente utile: il worker ora espone gli argomenti e le opzioni originali con cui il comando e stato avviato. Questo e fondamentale per diversi scenari operativi.

Logging contestuale: i log del worker possono includere con quale configurazione e stato avviato, facilitando il debugging di problemi in produzione. "Perché questo worker non processa la coda X?" diventa una domanda con risposta immediata nei log.
Retry intelligente: un supervisore (Supervisor, systemd) che riavvia il worker può passare gli stessi argomenti originali, garantendo consistenza dopo un crash.
Dashboard operativo: un pannello di controllo può mostrare lo stato di ogni worker con la sua configurazione corrente, senza dover ispezionare i processi del sistema operativo.

JsonPath: funzioni custom per il tuo dominio

Il componente JsonPath, introdotto con Symfony 8.0 per navigare strutture JSON complesse, guadagna in Symfony 8.1 il supporto per funzioni custom. Questa estensione trasforma JsonPath da semplice strumento di navigazione a un vero linguaggio di query per dati JSON.

Come registrare funzioni custom

Le funzioni custom sono normali funzioni PHP registrate come estensioni del motore JsonPath. La registrazione avviene tramite il service container di Symfony, con tag dedicati che associano il nome della funzione JsonPath alla funzione PHP corrispondente.

Funzioni di trasformazione: normalizzare stringhe, convertire formati di date, arrotondare valori numerici — operazioni che si applicano durante l'estrazione, non dopo.
Funzioni di aggregazione: somme, medie, conteggi su sottoinsiemi di dati selezionati dall'espressione JsonPath. Utile per report e dashboard che consumano API esterne.
Funzioni di dominio: logiche specifiche dell'applicazione. Un e-commerce potrebbe registrare una funzione calculateDiscount usabile nelle espressioni JsonPath per calcolare sconti sui prezzi estratti da un feed di prodotti.

Combinare navigazione e trasformazione

La potenza delle funzioni custom emerge quando vengono combinate con le espressioni di navigazione. Un'espressione come $.products[?(@.price > 100)].price.avg() naviga ai prodotti costosi, estrae i prezzi e calcola la media — tutto in una singola espressione dichiarativa. Senza funzioni custom, questo richiederebbe codice PHP procedurale dopo l'estrazione.

Deep Cloner nel componente VarExporter

Il componente VarExporter guadagna un deep cloner: clonazione profonda di oggetti complessi senza implementare __clone() manualmente. Questo e più significativo di quanto sembri, perché la clonazione profonda in PHP e storicamente problematica.

Il problema della clonazione in PHP

L'operatore clone di PHP esegue una copia superficiale: le proprieta scalari vengono copiate, ma le proprieta che referenziano oggetti mantengono il riferimento all'oggetto originale. Modificare un oggetto annidato nel clone modifica anche l'originale — un bug subdolo e difficile da diagnosticare.

La soluzione classica e implementare __clone() in ogni classe, clonando manualmente ogni proprieta oggetto. Ma per grafi di oggetti complessi con relazioni circolari, l'implementazione corretta di __clone() e tutt'altro che banale.

Scenari d'uso del deep cloner

Snapshot di stato: salvare lo stato corrente di un oggetto complesso prima di modificarlo, per poter annullare le modifiche in caso di errore. Pattern comune in form wizard e processi multi-step.
Undo/redo: mantenere una cronologia di stati precedenti per funzionalita di undo. Ogni stato deve essere una copia completamente indipendente.
Test isolation: nei test, clonare un fixture object per ogni test case garantisce che le modifiche in un test non influenzino gli altri. Il deep cloner rende questo pattern affidabile senza implementare __clone() in ogni classe del dominio.
Parallel processing: in scenari di processing parallelo, ogni worker deve operare su una copia indipendente dei dati. Il deep cloner garantisce l'indipendenza senza serializzazione/deserializzazione.

L'impatto cumulativo dei miglioramenti incrementali

Singolarmente, ogni miglioramento in Symfony 8.1 sembra piccolo. Ma l'impatto e cumulativo. Un worker Messenger più controllabile in produzione significa meno incident e meno tempo di debugging. Funzioni JsonPath custom significano meno codice procedurale per elaborare dati JSON. Un deep cloner affidabile significa meno bug di condivisione stato nei test e nelle logiche di undo.

Per chi lavora come freelance PHP su progetti Symfony, questi miglioramenti si traducono in codice più robusto, meno ore di debugging e applicazioni che si comportano in modo più prevedibile in produzione. L'upgrade alla 8.1 e un investimento minimo (nessun breaking change) con un ritorno tangibile sulla qualità del codice.

👉 Leggi l'articolo completo su iadicola.it

Filament 5 e Laravel: pannelli admin in meta tempo

Dev-Iadicola — Thu, 17 Sep 2026 17:00:19 +0000

Cos e Filament e perché e diventato lo standard per i pannelli admin Laravel

Filament e un framework open source per costruire pannelli admin, dashboard e interfacce CRUD sopra Laravel. Non e un template preconfezionato e non e un page builder: e un ecosistema completo di componenti Livewire che generano interfacce professionali a partire dal codice PHP, senza scrivere HTML, CSS o JavaScript manualmente.

La filosofia di Filament e chiara: lo sviluppatore dichiara cosa vuole in PHP e il framework si occupa del rendering, della reattivita e dell esperienza utente. Questo approccio riduce drasticamente i tempi di sviluppo e mantiene il codice manutenibile, perché tutto vive in classi PHP con una struttura prevedibile.

Con la versione 5, Filament compie un salto di maturita significativo. Il redesign dell architettura interna porta miglioramenti concreti in performance, estensibilita e developer experience. Il supporto nativo per Laravel 12 e 13 garantisce compatibilità con le versioni più recenti del framework, mentre il nuovo sistema di rendering sfrutta il lazy loading dei componenti per ridurre il tempo di caricamento delle pagine più complesse.

Cosa cambia concretamente con Filament 5

Le novità della versione 5 non sono cosmetiche. Ogni cambiamento risolve problemi reali che gli sviluppatori affrontavano con la v4.

Compatibilità piena con Laravel 12/13 e Livewire 3.x — nessun workaround necessario, tutto funziona out of the box con le ultime versioni di Laravel e Livewire
Rendering più veloce con lazy loading — i componenti vengono caricati solo quando visibili nel viewport, riducendo il tempo di primo rendering del 40-60% su pagine con molti widget
Sistema di temi basato su CSS custom properties — personalizzare colori, font e spacing non richiede più la ricompilazione degli asset, basta cambiare le variabili CSS
Action modali con wizard multi-step — le azioni che richiedono più passaggi (conferma, raccolta dati, preview) si gestiscono con wizard integrati nelle modal, senza pagine dedicate
Plugin ecosystem maturo — oltre 200 pacchetti community disponibili, con un sistema di registrazione plugin più pulito e documentato
Miglioramenti al table builder — nuovi tipi di colonne, filtri più potenti e supporto nativo per l export in background di grandi dataset
Form builder potenziato — nuovi componenti come il color picker avanzato, il markdown editor e il file upload con drag and drop multiplo

Come Filament 5 accelera lo sviluppo di un pannello admin

Il vantaggio principale di Filament non e solo la velocità iniziale, ma la velocità di iterazione. Quando il cliente chiede una modifica — una colonna in più nella tabella, un filtro nuovo, un campo nel form — la modifica si fa in poche righe di PHP, senza toccare frontend, senza scrivere query SQL, senza gestire stato JavaScript.

Un esempio concreto: per aggiungere un campo "priorità" a una risorsa ordini, servono tre passaggi. Primo, aggiungere la colonna nel database con una migration. Secondo, aggiungere il campo nel form della Resource con Select::make('priority')->options([...]). Terzo, aggiungere la colonna nella tabella con TextColumn::make('priority')->badge(). Tempo totale: 5 minuti, incluso il test.

Il confronto con lo sviluppo tradizionale

Senza Filament, lo stesso pannello admin richiederebbe: progettazione del layout HTML, integrazione di un framework CSS, sviluppo dei componenti JavaScript per tabelle interattive, filtri e ordinamento, creazione dei form con validazione client-side e server-side, gestione delle rotte e dei controller, implementazione dell autenticazione e dei permessi. Settimane di lavoro per funzionalita che Filament offre in ore.

Quando ha senso usare Filament 5

Filament e la scelta giusta quando il progetto richiede un pannello admin strutturato con queste caratteristiche:

Gestione risorse CRUD — tabelle con ricerca, filtri, ordinamento e azioni in bulk
Form complessi — campi dinamici, relazioni, upload file, editor rich text
Dashboard con metriche — KPI, grafici, tabelle riepilogative aggiornate in tempo reale
Ruoli e permessi — accesso differenziato per tipo di utente
Multi-tenancy — più aziende o clienti sullo stesso applicativo

Non ha senso usare Filament per landing page, siti vetrina o applicazioni dove il pannello admin e un semplice CRUD con due tabelle. In quei casi, un controller Laravel con qualche view Blade e più che sufficiente.

Filament nel contesto freelance

Come sviluppatore freelance PHP, Filament 5 ha cambiato il modo in cui affronto i preventivi. Dove prima stimavo 3-4 settimane per un pannello admin completo, ora stimo 1-2 settimane con un risultato qualitativamente superiore. Il cliente ottiene un interfaccia professionale, reattiva e mobile-friendly senza costi aggiuntivi di design o sviluppo frontend.

Il risparmio di tempo si traduce in margini migliori sui progetti e nella possibilita di dedicare più ore alla logica di business specifica del cliente — che e dove si crea il vero valore.

Risorse per iniziare con Filament 5

La documentazione ufficiale di Filament e tra le migliori nell ecosistema Laravel: completa, con esempi pratici e organizzata per caso d uso. Il sito filamentphp.com include una sezione dedicata ai plugin, un marketplace di temi e una community Discord attiva con migliaia di sviluppatori.

Per chi arriva da zero, il consiglio e partire dalla guida "Getting Started" e costruire una Resource completa seguendo il tutorial. In meno di un ora si ha un pannello funzionante con tabella, form e autenticazione — la base per capire come Filament ragiona e come estenderlo per le proprie esigenze.

👉 Leggi l'articolo completo su iadicola.it

Anatomia del bootstrap: come Mvc.php orchestra una richiesta

Dev-Iadicola — Wed, 16 Sep 2026 22:50:08 +0000

Il punto di ingresso: index.php

Tutto inizia da index.php, un file di poche righe che fa tre cose: carica l'autoloader di Composer, legge la configurazione (file .env e directory config/), e istanzia Mvc passandogli la ConfigCollection. Poi chiama $mvc->run() e la richiesta prende vita.

Questa separazione tra costruzione e avvio e intenzionale. Il costruttore prepara gli oggetti fondamentali — Request, Response, View, Router — senza effetti collaterali. Il metodo run() attiva i provider, connette il database, e risolve la richiesta. Se qualcosa va storto nella fase di boot, il framework può reagire prima di tentare di risolvere una route.

Il costruttore: preparare il terreno

Il costruttore di Mvc inizializza gli error handler per primi. NativeErrorProvider registra un handler PHP che intercetta errori e warning nativi e li scrive nel file app.log. Subito dopo, WhoopsProvider registra Whoops come exception handler — in modalita sviluppo, Whoops fornisce stack trace dettagliati e interattivi nel browser; in produzione viene disattivato a favore di pagine di errore pulite.

L'ordine conta: gli error handler devono essere attivi prima di qualsiasi altra inizializzazione. Se il database fallisce o una configurazione e errata, vogliamo un messaggio di errore leggibile, non un fatal error di PHP.

Poi vengono creati gli oggetti HTTP. Request incapsula la richiesta corrente: metodo, URI, parametri GET/POST, header, body. View riceve il riferimento a Mvc per accedere alla configurazione durante il rendering. Response riceve la View per poter renderizzare le pagine. Router riceve l'intero Mvc perché deve orchestrare la risoluzione delle route e il dispatch ai controller.

Infine, self::$mvc = $this rende l'istanza accessibile globalmente. La funzione helper mvc() restituisce Mvc::$mvc, permettendo a qualsiasi parte del codice di accedere a Request, Response, Config e agli altri servizi senza dependency injection esplicita. E un Service Locator — un compromesso pragmatico: non ha l'eleganza della pura DI, ma evita di passare sei parametri a ogni costruttore in un framework dove il container non e un full-blown DI container.

La sequenza di boot in run()

Il metodo run() avvia i servizi nell'ordine in cui dipendono l'uno dall'altro. Ogni step ha una ragione precisa per la sua posizione nella sequenza:

SessionStorage — primo, perché tutto il resto (CSRF, auth, flash messages) dipende dalla sessione. Il singleton configura cookie sicuri (HttpOnly, Strict mode, Secure su HTTPS, SameSite=Lax) e avvia la sessione PHP
EncryptionService — secondo, perché valida la APP_KEY immediatamente. Se manca o e malformata, l'applicazione si ferma qui con un messaggio chiaro, prima di qualsiasi query al database o rendering di view
DatabaseProvider — crea la connessione PDO attraverso il DatabaseDriverFactory. Se la connessione fallisce, il provider gestisce l'errore in base all'ambiente: in debug mostra l'eccezione, in produzione redirige a una pagina di errore. Il PDO viene salvato in $this->pdo per essere accessibile globalmente
ORM Runtime — riceve il PDO e il nome del driver (mysql, pgsql, sqlite, mariadb). Questo registry e il punto di verità per tutti i componenti ORM: modelli, query builder, migrazioni. Separarlo dal DatabaseProvider permette di cambiare driver senza modificare il codice ORM
CacheManager — inizializzato con la configurazione da config/cache.php. Supporta cache file-based con invalidazione per tag (tabella). Deve venire dopo il database perché alcune operazioni di cache possono richiedere query
SmtpProvider — carica le credenziali SMTP dall'ambiente e crea il trasporto mail. Viene dopo il database perché in alcuni scenari i template email possono accedere a dati dal database
CsrfService — ultimo prima del routing, genera il token CSRF se non ne esiste uno in sessione. Dipende da SessionStorage (per salvare il token) e da EncryptionService (per la chiave HMAC)

Risoluzione della route e dispatch

Dopo il boot dei provider, $this->router->resolve() prende il controllo. Il Router legge il metodo HTTP e l'URI dalla Request, cerca un match nella route collection (caricata dagli attributi dei controller o dalla cache), applica i middleware globali e poi quelli specifici della route, e infine chiama il metodo del controller.

L'intera risoluzione e avvolta in un try/catch per Throwable. Se il controller o un middleware lanciano un'eccezione, ExceptionHandler::handle() la intercetta, la mappa a un codice HTTP appropriato (404 per NotFoundException, 422 per ValidationException, 401 per UnauthorizedException), e genera la risposta di errore — JSON per le API, pagina HTML per il web.

Dopo la risoluzione (riuscita o fallita), $this->response->send() invia gli header HTTP e il body al client. La Response accumula header e contenuto durante tutto il ciclo, e li emette in un unico momento alla fine. Questo permette ai middleware di modificare la risposta anche dopo che il controller ha scritto il suo output.

Il pattern Provider

I Provider sono classi con un metodo register() che incapsulano la logica di inizializzazione di un servizio. DatabaseProvider gestisce la connessione PDO con error handling specifico per ambiente. SmtpProvider configura il trasporto mail. WhoopsProvider registra l'exception handler.

Il vantaggio del pattern Provider e l'isolamento: se la configurazione SMTP cambia, modifico solo SmtpProvider. Se aggiungo un nuovo servizio (un client Redis, un message broker), creo un nuovo Provider e lo inserisco nella sequenza di boot al punto giusto. Ogni provider sa come inizializzare il suo servizio e come gestire i fallimenti — il run() non deve preoccuparsi dei dettagli.

Perché non un vero DI Container

Framework come Laravel e Symfony usano container di dependency injection completi con binding, risoluzione automatica e autowiring. Soft PHP MVC usa un approccio più semplice: un Service Locator (Mvc::$mvc) con provider manuali. La ragione e pragmatica: un DI container aggiunge complessità che si giustifica in applicazioni con centinaia di servizi e team di decine di sviluppatori. In un framework personale con una dozzina di servizi, sapere esattamente cosa viene inizializzato, in che ordine e perché, vale più dell'eleganza del container automatico.

Il compromesso e consapevole: il codice dipende dall'helper mvc() invece che da interfacce iniettate. Se un giorno servira un container, la migrazione sara graduale — i provider già incapsulano la logica di creazione, basterebbe registrarli in un container invece che chiamarli manualmente nel run().

👉 Leggi l'articolo completo su iadicola.it

CRUD con Filament 5: da migration a pannello in 15 minuti

Dev-Iadicola — Wed, 16 Sep 2026 21:45:12 +0000

Il flusso di lavoro CRUD con Filament 5: dalla migration al pannello funzionante

Con Filament 5 il percorso per creare un interfaccia CRUD completa e lineare e ripetibile. Si parte dalla migration del database, si crea il model Eloquent e poi si genera la Resource con un comando Artisan. Il risultato e una pagina di listing con tabella interattiva, filtri e ricerca, più pagine di creazione e modifica con form validato — tutto generato dal codice PHP senza toccare una riga di HTML o JavaScript.

Questo flusso non e solo veloce la prima volta: e il modo in cui si lavora costantemente con Filament. Ogni nuova entita del progetto segue lo stesso pattern, il che rende il codice prevedibile e facile da manutenere anche per chi si aggiunge al team mesi dopo.

Cosa ottieni immediatamente con una Resource Filament

Generare una Resource con php artisan make:filament-resource produce una struttura completa che include già tutto il necessario per un CRUD professionale:

Tabella con colonne sortabili — ogni colonna e cliccabile per ordinare i dati in modo ascendente o discendente, con indicatore visivo dell ordinamento attivo
Ricerca globale e per campo — la barra di ricerca cerca su tutti i campi configurati come searchable, con debounce automatico per non sovraccaricare il database
Filtri per campo — select, date range, toggle e filtri custom che si applicano in tempo reale grazie a Livewire
Form con campi tipizzati — text input, textarea, select, date picker, file upload, rich editor, toggle, radio, checkbox group e molti altri
Validazione integrata — usa le stesse regole di validazione di Laravel, dichiarate direttamente nel form schema
Azioni in bulk — seleziona più record e applica azioni come elimina, esporta o cambia stato con un click
Soft delete e restore — con un semplice toggle nella Resource, i record eliminati vengono nascosti ma recuperabili
Paginazione configurabile — numero di record per pagina, stile di paginazione e contatore totale

Esempio pratico: gestionale ordini da zero

Vediamo un caso concreto. Il cliente ha bisogno di un gestionale ordini con queste funzionalita: lista ordini con filtri per stato e data, dettaglio ordine con dati cliente e prodotti, modifica stato e note, export in CSV.

Step 1: migration e model

Si crea la migration con i campi necessari: customer_id, status, total, notes, created_at. Il model Order definisce le relazioni con Customer e OrderItem, i cast per i campi monetari e gli scope per i filtri.

Step 2: generare la Resource

Il comando php artisan make:filament-resource Order --generate analizza il model e genera automaticamente la Resource con form e tabella basati sui campi del database. Il flag --generate e il punto di partenza: produce codice funzionante che poi si personalizza.

Step 3: personalizzare la tabella

Nella classe OrderResource, il metodo table() definisce le colonne visibili. Si aggiungono colonne calcolate come il nome del cliente dalla relazione, badge colorati per lo stato dell ordine, formattazione monetaria per il totale e filtri per data e stato. Il tutto con metodi chainable che rendono il codice leggibile e dichiarativo.

Step 4: personalizzare il form

Il metodo form() definisce i campi di creazione e modifica. Si configura un select con ricerca per il cliente, un select per lo stato con colori associati, un campo monetario per il totale e un textarea per le note. La validazione si aggiunge inline: ->required(), ->numeric(), ->min(0).

Gestione delle relazioni nel CRUD

Uno degli aspetti più potenti di Filament e la gestione delle relazioni Eloquent direttamente nel pannello admin. Non serve scrivere controller separati per le entita correlate: tutto si gestisce dalla Resource principale.

BelongsTo — select con ricerca che carica i record dalla tabella correlata, con possibilita di creare nuovi record inline
HasMany — relation manager che mostra una tabella dei record figli con CRUD completo nella stessa pagina
BelongsToMany — gestione della tabella pivot con attach, detach e sync, con possibilita di aggiungere campi extra alla pivot
MorphMany — supporto per relazioni polimorfiche, utili per commenti, tag e media associati a più entita

Nel caso del gestionale ordini, la relazione HasMany con OrderItem permette di gestire le righe d ordine direttamente nella pagina dell ordine, con tabella dedicata e possibilita di aggiungere, modificare ed eliminare righe senza navigare via dalla pagina.

Il vantaggio reale: la velocità di iterazione

Il vero punto di forza del CRUD con Filament non e solo la velocità di setup iniziale — che comunque e notevole — ma la velocità con cui si risponde alle richieste di modifica del cliente.

Il cliente chiede una nuova colonna nella tabella? Una riga di codice. Un filtro aggiuntivo? Tre righe. Un campo nel form con validazione? Cinque righe. Un export CSV? Un plugin da installare e configurare in 10 minuti.

Questa velocità di iterazione cambia la dinamica del rapporto con il cliente. Invece di accumulare richieste per la prossima release, si implementano le modifiche in tempo reale durante la call. Il cliente vede il risultato subito, conferma o corregge il tiro, e si va avanti. Meno email, meno malintesi, meno ore buttate su specifiche fraintese.

Quanto codice serve davvero?

Per dare un idea concreta: un CRUD completo per una risorsa con 10 campi, relazioni, filtri e azioni richiede mediamente 80-120 righe di PHP. Lo stesso risultato costruito a mano con controller, form request, view Blade e JavaScript richiederebbe 500-800 righe distribuite su 8-10 file. Il rapporto e circa 1 a 6 in termini di codice da scrivere e manutenere.

Best practice per CRUD scalabili con Filament

Dopo diversi progetti con Filament, queste sono le pratiche che fanno la differenza sulla manutenibilità a lungo termine:

Usare gli Enum per gli stati — invece di stringhe sparse nel codice, definire un PHP Enum per ogni campo con valori fissi. Filament supporta gli Enum nativamente nei select e nei badge
Separare la logica pesante in Action — le operazioni complesse (invio email, calcoli, integrazioni esterne) vanno in classi Action dedicate, non inline nella Resource
Configurare i global scope con attenzione — se il model ha global scope (es. soft delete, tenant), assicurarsi che la Resource li gestisca correttamente con i filtri appropriati
Testare le Resource — Filament fornisce helper per i test: assertCanSeeTableRecords, assertFormFieldExists e simili rendono i test delle Resource veloci da scrivere

Queste pratiche non sono specifiche di Filament, ma la struttura del framework le rende naturali da applicare. Il codice dichiarativo delle Resource spinge verso un design pulito, dove ogni pezzo ha il suo posto e le responsabilità sono chiare.

👉 Leggi l'articolo completo su iadicola.it

Dashboard personalizzate con Filament 5 e widget Livewire

Dev-Iadicola — Wed, 16 Sep 2026 20:40:07 +0000

Filament oltre il CRUD: dashboard operative in tempo reale

Filament non serve solo per gestire tabelle e form. Uno degli aspetti più sottovalutati del framework e il sistema di widget, che permette di costruire dashboard operative con statistiche, grafici e dati aggregati che si aggiornano in tempo reale grazie a Livewire. Per molti clienti, la dashboard e la pagina più importante dell intero pannello admin: e quella che aprono ogni mattina per capire come sta andando il business.

Ogni widget in Filament e un componente PHP autonomo che definisce i propri dati, il layout e la logica di aggiornamento. Si compongono nella dashboard come blocchi, senza toccare HTML. La potenza sta nella semplicità: dichiari i dati in PHP e Filament si occupa del rendering, della reattivita e del layout responsive.

I tipi di widget disponibili in Filament 5

Filament 5 mette a disposizione quattro tipi di widget principali, ognuno ottimizzato per un caso d uso specifico. Combinandoli si costruiscono dashboard che coprono qualsiasi esigenza informativa.

Stat widget: KPI e metriche chiave

Il widget più usato nelle dashboard business. Mostra un valore numerico con label, icona opzionale e indicatore di trend (percentuale di variazione rispetto al periodo precedente). Ideale per fatturato, numero ordini, utenti attivi, ticket aperti e qualsiasi metrica che il cliente vuole monitorare a colpo d occhio.

Ogni stat widget può avere un colore che cambia in base al valore — verde se il trend e positivo, rosso se negativo — e un link che porta alla pagina di dettaglio per approfondire il dato.

Chart widget: grafici interattivi con Chart.js

Filament integra Chart.js per generare grafici a linee, barre, torta, area e radar. Il widget chart si dichiara in PHP specificando i dataset e le label, e Filament si occupa del rendering JavaScript. I grafici sono interattivi: hover per il dettaglio, click per filtrare, zoom su periodi specifici.

Per un e-commerce, un grafico a linee con l andamento del fatturato giornaliero degli ultimi 30 giorni, sovrapposto allo stesso periodo dell anno precedente, si implementa in una classe PHP di 30-40 righe. Senza Filament, lo stesso grafico richiederebbe un controller per i dati, una chiamata AJAX, la configurazione di Chart.js nel frontend e la gestione del layout responsive.

Table widget: tabelle compatte per dati recenti

Una versione ridotta del table builder di Filament, pensata per mostrare dati tabulari direttamente nella dashboard. Perfetta per gli ultimi ordini, i ticket più urgenti, i prodotti in esaurimento o qualsiasi lista che richiede attenzione immediata.

Il table widget supporta le stesse colonne e formattazioni del table builder completo, ma in un formato compatto che si integra nel layout della dashboard senza dominare la pagina.

Custom widget: componenti Livewire personalizzati

Quando i widget standard non bastano, si crea un custom widget che e a tutti gli effetti un componente Livewire. Si ha accesso completo al rendering Blade, alla reattivita di Livewire e a qualsiasi libreria JavaScript necessaria. Questo e utile per mappe interattive, timeline di eventi, feed in tempo reale o integrazioni con servizi esterni.

Esempio reale: dashboard per un e-commerce

Un caso concreto che ho implementato per un cliente. La richiesta: una dashboard che mostri la situazione del business in tempo reale, senza bisogno di aprire report o fogli di calcolo.

Riga superiore con 4 stat widget — fatturato giornaliero con trend rispetto alla settimana precedente, ordini del giorno, carrelli abbandonati e tasso di conversione
Grafico a linee — andamento fatturato ultimi 30 giorni con confronto anno precedente
Grafico a torta — distribuzione ordini per stato (in lavorazione, spediti, consegnati, resi)
Tabella ultimi 10 ordini — con nome cliente, importo, stato e link al dettaglio
Alert prodotti in esaurimento — tabella dei prodotti con stock sotto la soglia minima, con link diretto alla pagina di modifica

Il cliente apre il browser ogni mattina e ha subito la fotografia completa del business. Nessun export, nessun foglio di calcolo, nessuna email con report allegati. I dati sono sempre aggiornati e la dashboard si aggiorna automaticamente ogni 30 secondi grazie al polling di Livewire.

Aggiornamento in tempo reale: polling e WebSocket

Filament offre due strategie per mantenere i widget aggiornati. La prima e il polling: ogni widget può definire un intervallo di aggiornamento (es. ogni 10 secondi) e Livewire si occupa di fare la richiesta al server e aggiornare il DOM. Semplice e funziona senza configurazione aggiuntiva.

La seconda strategia e l integrazione con Laravel Echo e WebSocket per aggiornamenti push in tempo reale. Quando un evento viene dispatchato — un nuovo ordine, un pagamento confermato — il widget si aggiorna istantaneamente senza aspettare il polling. Questa strategia e ideale per dashboard di monitoraggio operativo dove anche pochi secondi di ritardo contano.

Quale strategia scegliere?

Il polling e sufficiente per la maggior parte dei casi: dashboard business, report giornalieri, metriche che cambiano lentamente. I WebSocket servono quando i dati cambiano frequentemente e l utente ha bisogno di vederli subito: monitoraggio ordini in tempo reale, chat di supporto, sistemi di alerting.

Organizzazione delle dashboard: pagine multiple e filtri globali

Un pannello admin complesso può avere bisogno di più dashboard: una per le vendite, una per il magazzino, una per il marketing. Filament supporta pagine dashboard multiple, ognuna con i propri widget e il proprio layout. Il menu laterale del pannello mostra le varie dashboard come voci separate.

I filtri globali permettono di cambiare il periodo temporale — oggi, ultima settimana, ultimo mese, custom range — e tutti i widget della dashboard si aggiornano di conseguenza. Questo evita di dover implementare filtri individuali per ogni widget e garantisce consistenza nei dati mostrati.

Performance delle dashboard con molti widget

Una dashboard con 10-15 widget può diventare lenta se ogni widget esegue query pesanti al caricamento. Filament 5 risolve questo problema con il lazy loading: i widget vengono caricati in modo asincrono, mostrando uno skeleton placeholder mentre i dati vengono recuperati. L utente vede la pagina subito e i widget si popolano man mano.

Per query particolarmente pesanti — aggregazioni su milioni di record, join complessi — il consiglio e usare tabelle materializzate o cache Redis con invalidazione basata su eventi. Il widget legge dalla cache e la cache viene aggiornata quando i dati cambiano. Il risultato: dashboard che caricano in meno di un secondo anche con dataset enormi.

In definitiva, le dashboard di Filament 5 trasformano un pannello admin da semplice strumento di gestione dati a centro di comando operativo. Il cliente smette di chiedere report via email e inizia a prendere decisioni basate su dati aggiornati in tempo reale — e questo e il valore più grande che un pannello admin può offrire.

👉 Leggi l'articolo completo su iadicola.it

La filosofia Unix nella CLI di un framework PHP

Dev-Iadicola — Wed, 16 Sep 2026 19:35:11 +0000

Do one thing and do it well

Nel 1978 Doug McIlroy sintetizzo la filosofia Unix in tre righe. La prima — fai una cosa sola e falla bene — e forse il principio di design più citato e meno applicato nella storia del software. E facile da capire, difficile da rispettare: la tentazione di aggiungere "un'altra piccola cosa" a un componente e costante, e prima che te ne accorga hai un oggetto che fa tutto e non fa niente bene.

Quando ho riscritto la CLI di Soft PHP MVC, questa tensione era ovunque. I vecchi comandi avevano cinque implementazioni diverse per il parsing degli argomenti. Ogni comando leggeva le opzioni a modo suo, gestiva gli errori a modo suo, produceva output a modo suo. Funzionava, ma ogni nuovo comando richiedeva di reinventare le stesse soluzioni — o peggio, di copiare codice da un comando esistente sperando che reggesse.

Il problema non era solo tecnico. Era concettuale: mancava un linguaggio condiviso tra i comandi. Senza una base comune, ogni sviluppatore (anche quando lo sviluppatore sei solo tu, sei mesi dopo) deve decifrare le convenzioni locali di quel singolo comando prima di poterlo modificare. La filosofia Unix non e solo efficienza — e comunicazione.

#[CliCommand]: dare un nome alle cose

Ludwig Wittgenstein scrisse che i limiti del linguaggio sono i limiti del mondo. Nel codice, dare un nome esplicito a qualcosa — un attributo, una classe, un metodo — non e solo una questione estetica: e un atto di comprensione. #[CliCommand('migrate:fresh', 'Drop all tables and re-run migrations', group: 'database')] non e solo metadata: e una dichiarazione di intenti. Il comando sa chi e, cosa fa, e dove appartiene.

L'uso degli attributi PHP 8.4 per dichiarare i comandi CLI rappresenta una scelta architetturale precisa. A differenza di un file di configurazione YAML o di un array centralizzato, l'attributo vive accanto al codice che descrive. Non c'e disallineamento possibile tra la dichiarazione e l'implementazione: se sposti il file, la dichiarazione si sposta con lui. Se rinomini la classe, il comando resta definito nel posto giusto.

L'auto-discovery via CommandDiscovery e il corollario naturale: se ogni comando si dichiara esplicitamente tramite attributi, il framework non ha bisogno di una registrazione manuale. Scansiona, riflette, raccoglie. Il Kernel non mantiene più una lista hardcoded di 25 comandi — la genera da cio che trova. Meno codice da mantenere, meno possibilita di dimenticare una registrazione.

Il ruolo della Reflection API

Sotto il cofano, CommandDiscovery usa la Reflection API di PHP per leggere gli attributi a runtime. Questo e un esempio di metaprogrammazione pragmatica: il codice ispeziona se stesso per costruire la mappa dei comandi disponibili. Non serve un compilatore separato, non serve un passo di build — il framework si auto-configura ogni volta che parte, leggendo la struttura delle proprie classi.

Input e Output: i confini del comando

La classe Input unifica cinque pattern di parsing in uno solo: argomenti posizionali, flag booleani, coppie chiave-valore, flag corti combinati (-mcs), lookahead. La classe Output offre metodi tipizzati — info(), success(), error(), table() — senza chiamare mai exit() direttamente. Un comando che non chiama exit() e un comando testabile.

Questa separazione ricorda la distinzione kantiana tra fenomeno e noumeno, trasposta nel software: il comando non conosce il "mondo esterno" (lo stdin, lo stdout, il terminale). Conosce solo le astrazioni che Input e Output gli presentano. Potrebbe girare in un terminale, in un test, in un pipe — non gli interessa e non dovrebbe interessargli.

Perché i metodi tipizzati contano

La differenza tra echo "Migrazione completata" e $output->success('Migrazione completata') sembra cosmetica, ma ha conseguenze profonde. Il metodo tipizzato codifica l'intenzione semantica del messaggio: success indica un risultato positivo, error un fallimento, info un dato neutro. Questa semantica può essere usata in molti modi: colorare l'output nel terminale, filtrare i log in produzione, formattare i risultati in JSON per un consumatore automatico. Con echo, il messaggio e solo una stringa — il significato si perde.

Command base class: il contratto implicito

La classe astratta Command stabilisce un lifecycle chiaro: handle(Input, Output): int. Il codice di ritorno e un intero — 0 per successo, qualsiasi altro valore per errore. E il contratto più semplice possibile, e proprio per questo e il più robusto. Non c'e ambiguita su cosa significhi "il comando e riuscito": restituisce zero.

Il metodo factory make() garantisce che ogni comando venga istanziato allo stesso modo. L'help auto-generato legge gli attributi e le definizioni di argomenti e opzioni, eliminando la necessita di scrivere manualmente la documentazione di ogni comando. Se il codice e la documentazione divergono, la documentazione mente — generarla dal codice elimina questa classe di bug.

L'help auto-generato come documentazione vivente

Quando esegui php soft help migrate:fresh, il framework non legge un file markdown o una stringa hardcoded. Legge gli attributi #[CliCommand], gli argomenti definiti via addArgument() e le opzioni definite via addOption(), e compone l'help screen in tempo reale. Questa e documentazione vivente: non può divergere dal codice perché e il codice. Un principio che Martin Fowler chiamerebbe "executable specification" — la specifica che si esegue da sola.

26 comandi, un solo pattern

Migrare 26 comandi alla nuova architettura non e stato un esercizio di refactoring cosmetico. E stato un esercizio di disciplina: trovare cio che era comune, estrarlo, e lasciare a ogni comando solo cio che lo rende unico. make:model genera file da stub. migrate:fresh ricrea il database. key:generate produce una chiave crittografica. Tre comandi completamente diversi che condividono la stessa infrastruttura senza che questa li vincoli.

Elenco dei gruppi di comandi in Soft PHP MVC

database — migrate, migrate:fresh, migrate:rollback, seed: gestione completa del ciclo di vita del database
make — make:model, make:controller, make:middleware, make:command: generazione di codice da stub con placeholder
cache — cache:clear, view:clear: gestione della cache applicativa e delle view compilate
security — key:generate, csrf:rotate: operazioni crittografiche e di sicurezza
maintenance — up, down, serve: gestione dello stato dell'applicazione

Ogni gruppo condivide convenzioni di naming (verbo:risorsa), stile di output, gestione degli errori. Un nuovo sviluppatore che ha visto un comando sa come funzionano tutti gli altri. Questa prevedibilita e il vero valore della filosofia Unix applicata al codice PHP.

La filosofia Unix non e solo un principio tecnico. E un'etica del design: rispetta chi verra dopo di te. Un comando che fa una cosa sola, con un'interfaccia chiara e un output prevedibile, e un comando che qualcuno potra usare, estendere e debuggare senza dover leggere tutto il codice del framework. In un'epoca in cui la complessità cresce esponenzialmente, la semplicità e un atto di resistenza — e forse l'unico che ha davvero impatto duraturo.

👉 Leggi l'articolo completo su iadicola.it

Multi-tenancy con Filament 5: un pannello, più aziende

Dev-Iadicola — Wed, 16 Sep 2026 18:30:07 +0000

Il problema della multi-tenancy nello sviluppo web

Quando lo stesso applicativo deve servire più aziende o clienti, ogni tenant deve vedere solo i propri dati, avere i propri utenti e potenzialmente un branding diverso. Costruire questa separazione da zero e complesso, soggetto a errori di sicurezza e richiede un architettura pensata fin dal primo giorno. Un errore nello scope delle query significa che un azienda vede i dati di un altra — uno scenario inaccettabile.

Il problema non e solo tecnico: e anche organizzativo. Ogni tenant può avere esigenze diverse in termini di permessi, workflow e personalizzazione dell interfaccia. Gestire questa variabilita senza che il codice diventi un groviglio di if-else e una sfida architetturale seria.

Come Filament 5 risolve la multi-tenancy

Filament 5 ha il supporto multi-tenancy integrato nel core del framework, non come plugin esterno. Ogni panel può essere configurato con un tenant model — tipicamente Team, Organization o Company — e tutte le query vengono automaticamente filtrate per il tenant attivo. Non serve aggiungere where manuali in ogni query: Filament applica il filtro a livello globale.

L implementazione si basa su un concetto semplice: l utente appartiene a uno o più tenant tramite una relazione Eloquent, e il pannello filtra tutto in base al tenant selezionato. Il cambio di tenant avviene tramite un menu nel pannello, senza logout e senza perdere il contesto di navigazione.

Cosa si ottiene con la multi-tenancy di Filament

Scope automatico su tutte le query — ogni Resource, ogni widget, ogni relazione viene automaticamente filtrata per il tenant attivo. Non serve ricordare di aggiungere il filtro: Filament lo fa per te
Switch tenant senza logout — l utente che appartiene a più organizzazioni passa dall una all altra con un click, mantenendo la sessione attiva
Registrazione tenant con onboarding — flusso di creazione nuovo tenant personalizzabile con wizard multi-step per raccogliere i dati iniziali
Permessi per tenant — lo stesso utente può avere ruoli diversi in organizzazioni diverse. Admin in un azienda, viewer in un altra
Branding per tenant — logo, colori, nome e favicon personalizzati per ogni tenant, senza deployment separati
Billing e subscription — integrazione con sistemi di pagamento per gestire piani e limiti per tenant

Architettura: database condiviso vs separato

La multi-tenancy di Filament supporta entrambi gli approcci, ma con trade-off diversi.

Database condiviso con colonna tenant_id

Approccio più comune e semplice da gestire. Tutte le tabelle hanno una colonna team_id (o equivalente) e Filament applica un global scope su ogni query. Vantaggi: una sola istanza del database, migration centralizzate, backup semplificato. Svantaggi: se lo scope viene dimenticato in una query custom, i dati di un tenant possono fuoriuscire.

Database separato per tenant

Ogni tenant ha il proprio database. Isolamento totale dei dati, performance prevedibili per tenant e possibilita di backup e restore individuali. Svantaggi: complessità operativa maggiore, migration da eseguire su ogni database, query cross-tenant impossibili senza logica aggiuntiva. Questo approccio ha senso per SaaS enterprise dove l isolamento dei dati e un requisito contrattuale.

Configurazione pratica: i passaggi chiave

Configurare la multi-tenancy in Filament 5 richiede pochi passaggi ben definiti:

Creare il model tenant — una classe Eloquent come Team con i campi necessari (nome, slug, logo, impostazioni)
Definire la relazione utente-tenant — tipicamente una BelongsToMany attraverso una tabella pivot con ruolo
Configurare il panel — nel PanelProvider, chiamare ->tenant(Team::class) per attivare la multi-tenancy
Aggiungere il trait ai model — ogni model che deve essere filtrato per tenant implementa il trait HasTenantScope
Personalizzare la registrazione — opzionalmente, definire un form di registrazione tenant con i campi necessari per l onboarding

Gestione dei permessi per tenant

Il plugin Shield di Filament si integra perfettamente con la multi-tenancy. Si definiscono ruoli e permessi a livello di tenant, così lo stesso utente può essere amministratore in un organizzazione e avere accesso limitato in un altra. Questo e fondamentale per consulenti, agenzie e professionisti che lavorano con più clienti contemporaneamente.

Quando serve la multi-tenancy

La multi-tenancy non e sempre necessaria e aggiunge complessità. Ha senso in questi scenari specifici:

SaaS multi-azienda — la stessa applicazione venduta a più clienti, ognuno con i propri dati e utenti
Gestionali multi-filiale — un azienda con più sedi o divisioni che devono operare in modo indipendente
Piattaforme white-label — applicazioni brandizzate diversamente per ogni cliente, con funzionalita e limiti configurabili
Marketplace con vendor — ogni venditore gestisce il proprio catalogo, ordini e clienti in modo separato

Se il progetto serve una sola azienda con un solo set di dati, la multi-tenancy e overkill. In quel caso, un semplice sistema di ruoli e permessi copre le esigenze senza complessità aggiuntiva.

Sicurezza e testing nella multi-tenancy

Il rischio più grande in un sistema multi-tenant e il data leaking: un tenant che vede o modifica i dati di un altro. Per questo motivo, il testing diventa critico.

Filament facilità il testing della multi-tenancy con helper dedicati. Si può simulare l accesso come utente di un tenant specifico e verificare che le query restituiscano solo i dati corretti. E buona pratica scrivere test che tentano esplicitamente di accedere a dati di un altro tenant e verificano che l accesso venga negato.

A livello infrastrutturale, e consigliabile usare middleware dedicati che verificano il tenant attivo a ogni richiesta e monitorare i log per accessi anomali. La sicurezza della multi-tenancy non e un aspetto da dare per scontato: va verificata attivamente con test automatizzati e audit periodici.

La multi-tenancy come valore per il freelance

Come sviluppatore freelance, la multi-tenancy di Filament apre opportunità interessanti. Invece di sviluppare un applicativo custom per ogni cliente, si sviluppa una piattaforma multi-tenant e la si vende come servizio. Il costo di sviluppo si ammortizza su più clienti, la manutenzione e centralizzata e ogni nuovo tenant e un ricavo aggiuntivo con costo marginale vicino allo zero.

Filament 5 rende questo modello di business praticabile anche per un freelance o un piccolo team, perché la complessità della multi-tenancy viene gestita dal framework invece che dal codice custom.

👉 Leggi l'articolo completo su iadicola.it

GDPR: quando il codice incontra l'etica

Dev-Iadicola — Wed, 16 Sep 2026 17:25:11 +0000

La privacy non e una feature: e un diritto

C'e una tentazione ricorrente nello sviluppo software: trattare la privacy come una checkbox da spuntare. Aggiungi un banner cookie, metti un link alla privacy policy, e hai "fatto il GDPR". Ma il Regolamento Generale sulla Protezione dei Dati non e una specifica tecnica da implementare — e un framework etico tradotto in legge. Dietro ogni articolo c'e un principio: i dati delle persone appartengono alle persone, non a chi gestisce il server.

Quando ho implementato la compliance GDPR in Soft PHP MVC, ho dovuto confrontarmi con questa distinzione. Non bastava aggiungere un popup: serviva ripensare come il codice tratta i dati degli utenti in ogni punto del flusso. La domanda non era "come aggiungo un cookie banner?" ma "cosa succede ai dati dell'utente dal momento in cui visita il sito fino a quando quei dati vengono cancellati?".

Questa prospettiva cambia tutto. Un approccio tecnico alla privacy si concentra sui requisiti minimi. Un approccio etico si chiede: "Se io fossi l'utente, mi sentirei rispettato da come questo software tratta i miei dati?" La risposta a questa domanda guida ogni decisione implementativa.

Il consenso come precondizione, non come default

Il VisitorTrackingMiddleware ora controlla $_COOKIE['cookie-consent'] === 'accepted' prima di registrare qualsiasi dato. Senza consenso esplicito, nessun IP viene salvato, nessun user agent viene tracciato. Sembra banale, ma il vecchio comportamento era l'opposto: tracciava tutto e il consenso era un'aggiunta cosmetica.

Questa inversione — da opt-out a opt-in — non e solo una questione legale. E un cambio di prospettiva filosofico che richiama il concetto kantiano di trattare le persone come fini, mai come mezzi. L'utente non e una riga in un database di analytics: e una persona che ha il diritto di scegliere cosa condividere.

L'implementazione tecnica del middleware

Il middleware si inserisce nella pipeline delle richieste HTTP con una logica precisa. Prima viene eseguito il check sul cookie di consenso. Se il consenso non e presente, il middleware non fa nulla — nessun dato viene raccolto, nessuna riga viene scritta nel database. Solo quando l'utente ha esplicitamente accettato, il middleware procede a registrare la visita con IP anonimizzato (ultimo ottetto sostituito con zero, in conformita con le raccomandazioni del Garante Privacy italiano), user agent, URL visitato e timestamp.

Cookie banner conforme EDPB

Il cookie banner e stato riscritto seguendo le linee guida EDPB (European Data Protection Board): categorie separate (essenziali sempre attivi, analytics opzionali), tre azioni distinte (accetta tutto, salva preferenze, rifiuta tutto), flag di sicurezza Secure e SameSite=Lax. Rifiutare deve essere facile quanto accettare — i dark pattern che rendono il "rifiuta" più difficile da trovare sono una violazione dello spirito del regolamento.

Anatomia del banner: scelte di design

Il banner presenta tre categorie di cookie chiaramente distinte:

Cookie essenziali — sessione PHP, token CSRF, preferenza cookie consent: sempre attivi, non disattivabili, necessari per il funzionamento base
Cookie analytics — tracking visite, conteggio pagine viste: opzionali, disattivati per default, attivabili con consenso esplicito
Cookie di terze parti — eliminati completamente: nessun Google Analytics, nessun Facebook Pixel, nessun tracker esterno

L'eliminazione totale dei cookie di terze parti e una scelta radicale ma coerente. Se il principio e il rispetto per l'utente, condividere i suoi dati con aziende il cui modello di business e la sorveglianza pubblicitaria contraddice quel principio. L'analytics interna, costruita nel framework stesso, fornisce i dati necessari senza cederne il controllo a nessuno.

Data retention: il diritto all'oblio nel codice

Il comando php soft clear:gdpr implementa la pulizia periodica dei dati personali: visitatori dopo 90 giorni, rate limits dopo 24 ore, sessioni dopo 7 giorni, log trace dopo 180 giorni. Non e sufficiente chiedere il consenso — bisogna anche non conservare i dati oltre il necessario.

La data retention e forse l'aspetto più trascurato della privacy nel software. Tendiamo ad accumulare dati "perché potrebbero servire" — un impulso comprensibile ma problematico. Ogni riga nel database e una responsabilità: può essere rubata, può essere esposta, può essere richiesta da un'autorità. Meno dati conservi, meno rischi corri.

Il principio di minimizzazione dei dati

L'articolo 5(1)(c) del GDPR parla di minimizzazione dei dati: raccogliere solo cio che e strettamente necessario per lo scopo dichiarato. Nel codice, questo si traduce in domande concrete. Serve davvero salvare l'IP completo? No — l'ultimo ottetto viene azzerato. Serve conservare la sessione dopo 7 giorni di inattivita? No — viene cancellata. Serve tenere i log di trace per sempre? No — 180 giorni sono sufficienti per il debugging, oltre diventa sorveglianza.

Il comando clear:gdpr può essere schedulato via cron per esecuzione automatica. Questo trasforma la data retention da "buona intenzione" a processo automatizzato — una distinzione fondamentale in un contesto normativo dove "avevamo intenzione di cancellare" non e una difesa accettabile.

Self-hosting: riprendere il controllo

Bootstrap CSS, jQuery, Font Awesome — tutti serviti da CDN di terze parti. Ogni richiesta a un CDN e un dato condiviso: l'IP dell'utente, il referer, il timing. Spostare queste risorse in locale sotto assets/vendor/ non e solo una questione di performance (niente DNS resolution extra, niente connessioni cross-origin): e una scelta di sovranita digitale.

Richard Stallman parlava di liberta del software in termini di controllo: se non controlli il software che usi, il software controlla te. Lo stesso principio si applica all'infrastruttura: se le risorse della tua applicazione dipendono da server di terze parti, la privacy dei tuoi utenti dipende dalle policy di quelle terze parti. Self-hosting e un atto di responsabilità.

Vantaggi tecnici del self-hosting

Oltre all'aspetto etico, il self-hosting delle dipendenze frontend offre vantaggi tecnici misurabili:

Zero DNS resolution aggiuntive — ogni CDN esterno richiede una risoluzione DNS separata, aggiungendo latenza al caricamento iniziale
Nessun rischio di downtime esterno — se il CDN di Bootstrap va offline, il tuo sito continua a funzionare
Cache controllata — puoi impostare header di cache aggressivi sapendo esattamente quando le risorse cambiano
Subresource Integrity nativa — non serve calcolare hash SRI perché le risorse sono già sotto il tuo controllo

Privacy by design, non privacy by afterthought

Il form contatti ora include un campo privacy_consent con validazione server-side, e il timestamp del consenso viene salvato nel database come prova ai sensi dell'Art. 7(1) del GDPR. Non e un dettaglio implementativo: e la differenza tra "abbiamo chiesto il consenso" e "possiamo dimostrare di aver chiesto il consenso".

La validazione avviene a livello server tramite il sistema di validazione del framework: required, accepted. Anche se il JavaScript lato client impedisce l'invio del form senza la spunta, la validazione server-side e la vera barriera. Il client mente — il server verifica.

Scrivere software che rispetta la privacy richiede un cambio di mentalita. Non e un layer che aggiungi alla fine: e una decisione architetturale che influenza ogni scelta, dalla struttura del database al flusso dei middleware. E, in ultima analisi, e una questione di rispetto — per le persone che useranno il tuo software e per i dati che ti affidano. Il GDPR, nel suo spirito migliore, non e un ostacolo burocratico: e un invito a costruire software che tratti le persone come persone, non come risorse da estrarre.

👉 Leggi l'articolo completo su iadicola.it

Form avanzati con Filament 5: relazioni, repeater e wizard

Dev-Iadicola — Wed, 16 Sep 2026 16:20:08 +0000

Perché i form reali non sono mai semplici

I form delle applicazioni reali non sono mai una lista piatta di campi di testo. Un ordine ha righe prodotto con quantità e prezzi. Un progetto ha milestone con task e scadenze. Un paziente ha visite mediche con esami allegati e prescrizioni. La complessità dei dati si riflette nella complessità dei form, e gestirla bene e una delle sfide più comuni nello sviluppo di pannelli admin.

Filament 5 affronta questa complessità con componenti dedicati che si dichiarano in PHP puro, senza JavaScript custom, senza gestione dello stato frontend e senza validazione duplicata tra client e server. Il form builder di Filament e probabilmente il componente più potente dell intero framework, e quello che giustifica da solo l adozione per molti progetti.

Gli strumenti chiave per form complessi

Repeater: campi dinamici che l utente aggiunge e rimuove

Il Repeater e il componente per gestire liste di dati variabili all interno di un form. L utente può aggiungere nuove righe, rimuoverle, riordinarle con drag and drop e compilarle con qualsiasi tipo di campo supportato da Filament.

Casi d uso tipici: righe di un ordine o preventivo, indirizzi multipli per un cliente, varianti di un prodotto (taglia, colore, prezzo), esperienze lavorative in un curriculum, allegati con metadati. Ogni riga del repeater può contenere qualsiasi combinazione di campi: text, select, date, file upload, toggle e anche altri repeater annidati per strutture dati ricorsive.

Il Repeater gestisce automaticamente la persistenza dei dati. Se e associato a una relazione HasMany, Filament crea, aggiorna ed elimina i record figli in modo automatico quando il form viene salvato. Non serve scrivere logica custom nel controller.

Relationship manager: gestione relazioni inline

Il Relationship Manager e un componente che aggiunge una tabella di record correlati direttamente nella pagina di dettaglio di una risorsa. A differenza del Repeater — che gestisce la relazione all interno del form — il Relationship Manager mostra una tabella separata con il proprio CRUD completo.

Esempio: nella pagina di dettaglio di un cliente, un Relationship Manager per gli ordini mostra la lista degli ordini con tabella, filtri e azioni. L utente può creare un nuovo ordine, modificarne uno esistente o eliminarlo, tutto senza navigare via dalla pagina del cliente.

Questo approccio e ideale quando i record correlati sono entita autonome con i propri campi e la propria logica, e non semplici righe di un form.

Wizard: form multi-step con validazione per sezione

Il Wizard suddivide un form lungo in passaggi logici, ognuno con i propri campi e la propria validazione. L utente naviga avanti e indietro tra i passaggi, e la validazione viene eseguita ad ogni transizione. Solo quando tutti i passaggi sono validi si può procedere al salvataggio.

Il vantaggio non e solo estetico: un form di 30 campi spaventa l utente, mentre gli stessi 30 campi distribuiti in 4 step da 7-8 campi risultano gestibili. La percentuale di completamento dei form aumenta significativamente quando si usa un wizard rispetto a un form piatto.

Dipendenze tra campi: logica condizionale nel form

Filament supporta dipendenze tra campi con i metodi ->visible(), ->hidden(), ->disabled() e ->reactive(). Quando un campo cambia valore, altri campi possono apparire, scomparire o cambiare le proprie opzioni in tempo reale.

Esempio: un select "tipo documento" con le opzioni Fattura, Nota di Credito e Preventivo. Selezionando Fattura, appaiono i campi per la ritenuta d acconto e il regime IVA. Selezionando Preventivo, appare un campo per la data di scadenza dell offerta. Tutto gestito in PHP con metodi dichiarativi, senza JavaScript.

Esempio concreto: form di creazione preventivo

Vediamo un caso reale implementato per un cliente. Un form di creazione preventivo con quattro step, ognuno con la propria logica e validazione.

Step 1 — Dati cliente: select con ricerca su anagrafica esistente, con possibilita di creare un nuovo cliente inline. Campi per ragione sociale, P.IVA, indirizzo e email di fatturazione
Step 2 — Righe preventivo: repeater con descrizione, quantità, prezzo unitario e sconto percentuale. Calcolo automatico del totale per riga e del totale generale. Possibilita di riordinare le righe con drag and drop
Step 3 — Condizioni: textarea per note e condizioni, select per termini di pagamento, date picker per validita dell offerta, toggle per inclusione IVA
Step 4 — Riepilogo: anteprima del preventivo con tutti i dati, totali calcolati e pulsante di conferma

Senza Filament, questo form richiederebbe un framework JavaScript per la gestione dello stato, componenti custom per il repeater con calcoli, validazione duplicata client-server, chiamate AJAX per la ricerca clienti e un template Blade complesso per il layout. Con Filament, tutto vive in una classe PHP di circa 150 righe, testabile e manutenibile.

Validazione avanzata nei form Filament

La validazione in Filament sfrutta il sistema di validazione di Laravel, il che significa accesso a tutte le regole built-in e la possibilita di creare regole custom. Ma ci sono alcune funzionalita specifiche di Filament che meritano attenzione:

Validazione real-time — i campi marcati come ->live() vengono validati mentre l utente digita, mostrando gli errori immediatamente
Validazione per step del wizard — ogni passaggio valida solo i propri campi, impedendo di procedere al passaggio successivo se ci sono errori
Validazione su repeater — le regole si applicano a ogni riga del repeater indipendentemente, con messaggi di errore specifici per riga
Validazione cross-field — regole come required_if, gt:field e different:field funzionano anche tra campi di sezioni diverse del form

Performance dei form complessi

Un form con molti campi reattivi e repeater può diventare lento a causa delle richieste Livewire ad ogni interazione. Filament 5 mitiga questo problema con il debouncing automatico, il batching delle richieste e la possibilita di rendere reattivi solo i campi che lo necessitano davvero.

La regola pratica e: usare ->live() solo sui campi che influenzano altri campi, e usare ->live(onBlur: true) quando la reattivita non serve in tempo reale ma solo quando l utente esce dal campo. Questo riduce il numero di richieste al server e mantiene il form scattante anche con 50+ campi.

Il vantaggio architetturale dei form dichiarativi

Il beneficio più grande dei form Filament non e la velocità di sviluppo — che pure e notevole — ma la manutenibilità. Un form dichiarativo in PHP e intrinsecamente più leggibile di un equivalente mix di HTML, JavaScript e PHP. Le regole di validazione sono vicine ai campi, la logica condizionale e esplicita e la struttura del form e visibile in un colpo d occhio.

Quando un nuovo sviluppatore apre la classe di una Resource Filament, capisce immediatamente quali campi ha il form, come sono validati, quali dipendenze esistono e come vengono salvati i dati. Questa leggibilità si traduce in meno bug, meno tempo per l onboarding e costi di manutenzione ridotti nel lungo termine.

👉 Leggi l'articolo completo su iadicola.it

Filament 5 vs Nova: quale scegliere nel 2026

Dev-Iadicola — Wed, 16 Sep 2026 15:15:10 +0000

Due approcci diversi allo stesso problema

Laravel Nova e il pannello admin ufficiale del framework, sviluppato e mantenuto dal team Laravel, disponibile con licenza a pagamento. Filament e un progetto open source, basato su Livewire, con una community in crescita esponenziale e un ecosistema di plugin che rivaleggia con quello di Nova per ampiezza e qualità.

Entrambi generano pannelli admin completi a partire da codice PHP, con tabelle, form, filtri e dashboard. Ma le filosofie sottostanti sono diverse, e la scelta tra i due dipende dal contesto del progetto, dal budget e dalle competenze del team.

Dove Filament 5 vince rispetto a Nova

Filament ha accumulato vantaggi significativi negli ultimi due anni, e la versione 5 consolida ulteriormente la sua posizione come strumento di riferimento per i pannelli admin Laravel.

Gratuito e open source — nessun costo di licenza per progetto. Per un freelance che sviluppa 10 pannelli admin all anno, il risparmio rispetto a Nova (99$ per progetto o 299$ per la licenza multi-sito) e sostanziale
Basato su Livewire — reattivita completa senza Vue.js nel frontend. Il team non ha bisogno di competenze JavaScript avanzate, tutto si gestisce in PHP. Questo riduce la complessità dello stack e i punti di failure
Ecosistema plugin più ampio e attivo — oltre 200 plugin community, molti dei quali gratuiti. Il marketplace di Filament include plugin per ogni esigenza comune: Shield per i permessi, Excel per l export, Media Library per i file, e decine di altri
Multi-tenancy integrata nel core — Nova richiede pacchetti di terze parti per la multi-tenancy. Filament la offre nativamente, con supporto completo per tenant switching, scope automatico e branding per tenant
Form builder più flessibile — wizard nativi, repeater con drag and drop, dipendenze tra campi e layout personalizzabili. Il form builder di Filament e più potente e più facile da estendere rispetto a quello di Nova
Table builder superiore — colonne personalizzabili, filtri avanzati, summarizer per totali, gruppi e azioni in bulk più granulari
Aggiornamenti più frequenti — essendo open source con una community attiva, Filament rilascia aggiornamenti e bugfix con cadenza molto più frequente di Nova

Dove Nova resta forte nel 2026

Nova non e un prodotto obsoleto. Ha ancora vantaggi specifici che lo rendono la scelta giusta in determinati contesti.

Supporto ufficiale Laravel — aggiornamenti garantiti dal team core di Laravel. Quando esce una nuova versione del framework, Nova e aggiornata in parallelo. Per aziende che hanno bisogno di SLA e supporto formale, questo conta
Integrazione più stretta con l ecosistema first-party — Nova si integra nativamente con Cashier, Scout, Horizon e gli altri pacchetti ufficiali Laravel, spesso con meno configurazione rispetto a Filament
Interfaccia stabile e prevedibile — Nova cambia poco tra una release e l altra. Per team grandi che hanno bisogno di stabilita e prevedibilita, questo e un vantaggio. Filament evolve più rapidamente, il che significa più funzionalita ma anche più cambiamenti da gestire
Documentazione curata dal team Laravel — la documentazione di Nova e scritta con lo stesso standard della documentazione di Laravel: completa, coerente e mantenuta professionalmente
Frontend basato su Vue.js — per team con competenze Vue, Nova offre possibilita di personalizzazione frontend più granulari rispetto a Filament, che limita volutamente l accesso al JavaScript

Confronto tecnico diretto

Mettiamo a confronto i due framework su aspetti tecnici specifici che influenzano la scelta quotidiana dello sviluppatore.

Creazione di una Resource CRUD

In entrambi i framework si genera una Resource con un comando Artisan. La struttura e simile: una classe PHP che definisce campi del form e colonne della tabella. La differenza principale e nel form builder: Filament offre più componenti built-in (wizard, repeater, builder blocks) mentre Nova richiede pacchetti aggiuntivi per le stesse funzionalita.

Personalizzazione dell interfaccia

Filament usa Tailwind CSS con custom properties per il theming, personalizzabile senza ricompilare. Nova usa Tailwind ma con un sistema di theming meno flessibile. Per personalizzazioni profonde, Nova richiede la creazione di componenti Vue custom, mentre Filament permette di pubblicare e modificare view Blade specifiche.

Performance e scalabilità

Filament basato su Livewire fa più richieste al server per le interazioni (ogni click e una richiesta HTTP). Nova basato su Vue.js gestisce più logica client-side. Su pannelli con molte interazioni simultanee, Nova può risultare più reattivo. Su pannelli standard con interazioni moderate, la differenza e impercettibile.

Testing

Entrambi supportano il testing con PHPUnit. Filament offre helper specifici come assertCanSeeTableRecords e assertFormFieldExists. Nova ha un set di assertion simile. La testabilita e comparabile.

La scelta pratica nel 2026

Dopo aver usato entrambi i framework in progetti reali, la mia raccomandazione per il 2026 e chiara:

Filament 5 per la maggior parte dei progetti nuovi. Zero costi di licenza, community attiva, funzionalita che coprono il 95% dei casi d uso e una curva di apprendimento accessibile. Per freelance e piccoli team, il risparmio economico e di tempo e significativo.

Nova per progetti enterprise con requisiti specifici. Team grandi che hanno bisogno di supporto ufficiale, SLA garantiti e stabilita a lungo termine. Aziende che sono già investite nell ecosistema Nova con plugin custom e workflow consolidati.

Cosa considerare prima di scegliere

Budget — Filament e gratuito, Nova costa 99$/progetto o 299$ multi-sito. Su 10 progetti, sono 990$ di differenza
Competenze del team — Filament richiede solo PHP e Livewire. Nova richiede anche Vue.js per personalizzazioni avanzate
Complessità dei form — se il progetto ha form complessi con wizard e repeater, Filament ha un vantaggio netto
Multi-tenancy — se serve, Filament la offre nativamente. Con Nova serve un pacchetto esterno
Stabilita vs innovazione — Nova cambia poco e lentamente. Filament evolve rapidamente. Entrambi sono validi, dipende da cosa serve al progetto

In definitiva, la competizione tra Filament e Nova ha alzato la qualità di entrambi gli strumenti. Il vero vincitore e lo sviluppatore Laravel, che nel 2026 ha due opzioni eccellenti per costruire pannelli admin professionali in tempi rapidi.

👉 Leggi l'articolo completo su iadicola.it