Symfony 4: Buone pratiche

Symfony 4 sarà pubblicato nel Novembre del 2017. Questa serie di articoli spiega le principali novità:

• Symfony 4 (parte 1): Comporre al posto di ereditare
• Symfony 4 (parte 2): Micro applicazioni e monoliti
• Symfony 4 (parte 3): Buone Pratiche
• Symfony 4 (parte 4): Struttura delle cartelle
• Symfony 4 (parte 5): Automatizzazione
• Symfony 4 (parte 6) (Prossimamente)
• Symfony 4 (parte 7) (Prossimamente)
• Symfony 4 (parte 8) (Prossimamente)

Quando si pubblica una versione maggiore di un progetto (come per esempio Symfony 2.0, 3.0, 4.0, etc.) è il momento perfetto pe ripensare alle buone pratiche è aggiornarle se necessaio. Symfony 4 non sarà un’eccezione e per questo è ora di adattare alcune delle buone pratiche attuali alle nuove funzionalità che introduce Symfony 4.

Standardizzazione prima cosa

Il primo passo nell’evoluzione delle migliori pratiche di Symfony sarà quello di utilizzare il maggior numero possibile di strumenti standard.

Symfony non smette di adottare gli standard sia web che PHP, quindi è difficile credere che quando abbiamo iniziato a sviluppare Symfony 2, Composer non esisteva ancora. Da allora, sono emerse iniziative come il “Gruppo FIG”, che sviluppa standard per PHP, denominati PSR (PHP Standards Recommendations).

Symfony è stato uno dei primi framework importanto ad adottare la maggior parte dei PSR e lo ha fatto senza rompere la compatibilità con le applicazioni esistenti: PSR-3 per i logs, PSR-4 per il caricamento automatico delle classi e PSR-6 per la memorizzazione nella cache. In Symfony 3.3 abbiamo aggiunto il supporto per PSR-16 (cache semplificata) e PSR-11 (contenitori di servizio).

L’uso di standard aumenta l’interoperabilità tra le applicazioni e consente di separare il codice dei tuoi progetti dal framework Symfony.

Applicazioni senza Bundle

Nell’articolo precedente abbiamo spiegato la decisione di smettere di utilizzare i bunndles nelle applicazioni Symfony. Lo ricordiamo qui semplicemente come un promemoria perché è uno dei cambiamenti più importanti delle nuove best practice di Symfony.

Variabili dell’ambiente

Il libro ufficiale di Buone Pratiche di Symfony spiega in dettaglio come gestire la configurazione delle applicazioni Symfony. Ad esempio, come utilizzare app/config/parameters.yml per le opzioni di configurazione relative all’infrastruttura (ad esempio, il database) e come utilizzare app/config/config.yml per le opzioni di configurazione relative alle applicazioni.

La nostra prima raccomandazione è che non si utilizzino le opzioni di configurazione salvate in app/config/config.yml a meno che non sia assolutamente necessario. Infatti, a nostro parere, si può contare sulle dita di una mano dove è necessario definire un’opzione di questo tipo.

D’altra parte, in Symfony 4 scompare anche il fileapp/config/parameters.yml. Al suo posto sono utilizzate le variabili di ambiente, come la maggior parte dei framework fa in altri linguaggi di programmazione. Inoltre, questa è una delle raccomandazioni dei 12 Fattori del Manifesto Applicativo che segue le piattaforme di hosting più moderne.

Anche se le variabili di ambiente non sono perfette, hanno diversi vantaggi rispetto all’utilizzo del file parameters.yml. Per cominciare, le variabili di ambiente sono il meccanismo standard dell’industria per gestire le impostazioni che dipendono dall’ambiente di esecuzione (ad esempio, sono molto più comode rispetto a quello che deve affrontare il file parameters.yml.dist).

Inoltre, le variabili di ambiente possono essere lette da strumenti diversi, in quanto indipendenti dal codice, dal framework e dal linguaggio di programmazione. Le variabili di ambiente sono utili anche nei sistemi di file di sola lettura perché sono disaccoppiati dal codice e il loro valore può essere modificato in modo dinamico senza dover ripristinare l’applicazione (e senza dover cancellare la cache dell’applicazione Symfony ).

Il loro unico inconveniente è che, a differenza di ciò che alcuni programmatori credono, le variabili di ambiente sono altrettanto insicure come i file di configurazione quando si tratta di mantenere valori segreti come le password e gli API tokens.

L’utilizzo di variabili d’ambiente durante lo sviluppo dell’applicazione è un po ‘pesante’, quindi consigliamo di utilizzare un file standard chiamato .env. Symfony 3.3 include un nuovo componente denominato Dotenv che sarà utilizzato per impostazione predefinita nelle applicazioni Symfony 4. Quindi, il cambio tra un file .env e le variabili di ambiente “reali” sarà automatica e trasparente per te.

Se preferisci, puoi ancora definire le variabili di ambiente in un file denominato parameters.yaml, anche se questo non sarà più la modalità standard di lavorare. A proposito, il nome parameters.yamlnon è un errore di scritture. Infatti, questo sarà un altro cambiamento di Symfony 4 che discuteremo in seguito.

Un ulteriore vantaggio di utilizzare le variabili di ambiente è semplificare il modo in cui viene gestito l’ambiente di runtime (dev, prod, etc.) eil valore dell’opzione debusia sulla console che sui front controller.

Attualmente si possono definire l’ambiente e il debug che si utilizzano con ./bin/console sia con le opzioni --env e --no-debug sia con le variabili di ambiente SYMFONY_ENV e SYMFONY_DEBUG. In Symfony 4 questo non sarà più necessario giacchè si utilizzeranno le variabili di ambiente APP_ENV y APP_DEBUG sia sulla console che sui controller.

Quindi puoi dimenticarti di ./bin/console foo:bar --env=prod --no-debug o SYMFONY_ENV=prod SYMFONY_DEBUG=0 ./bin/console foo:bar.
Basta usare ./bin/console foo:bar e tutto funzionerà come previsto. Sia nello sviluppo che nella produzione. A proposito, Symfony 4 è pieno di semplificazioni di questo tipo.

Un solo controller per il front

Symfony 3 dispone di due front controller. Uno è ottimizzato per la produzione (app.php) e l’altro per lo sviluppo (app_dev.php). Symfony 4 ha solo di un front controller, quindi non è più necessario eliminare il front controller di sviluppo dopo il deply dell’applicazione in produzione. Più nessun problema di sicurezza a causa della dimenticanza di cancellarlo.

Forse stai pensando che questo renderà il codice più complesso di prima. Questo non è vero, perché abbiamo potuto eliminare un sacco di codice vecchio. Tutto grazie alle variabili di ambiente, grazie a PHP 7 (che rende inutili i file di bootstrap e la cache di classe) e grazie a Symfony 3.3 (che elimina la necessità di utilizzare un loader di classi).

Il file Makefile

In molti progetti è solito avere script propri per eseguire delle attività: eseguire i test di unitari o di integrazione, avviare il server web interno PHP, ecc. In questi casi non ha molto senso creare un comando symfony per eseguire questo tipo di script.

È anche comune, per comodità, definire alcuni di questi script nel file composer.json dell’applicazione. Silex ad esempio lo fa con lo script che inizia il server web interno di PHP. L’inconveniente è che è difficile gestire cose come timeout o la mancanza di supporto per le sequenze di escape ANSI da comandi.

In entrambi i casi, sia nel file composer.json o altrove, avere tutti questi script centralizzati in un luogo è molto utile. E se usassimo un Makefile per questo? Questo è probabilmente il cambiamento più controverso di Symfony 4. Abbiamo discusso molto sul fatto di fare questo cambio oppure no. Alla fine abbiamo deciso di farlo perché porta grande valore e risolve alcuni dei nostri problemi.

Forse già conosci lo strumento make, perché è abbastanza noto e “standard” nel campo della programmazione. È uno strumento molto più potente degli script che esguiti da Composer. Inoltre non richiede l’uso di PHP. Può essere utilizzato per distribuire applicazioni, connettersi tramite SSH a server remoti, eseguire npm, gulp, webpack, Blackfire, ecc. In breve, molti casi di utilizzo in cui i comandi tradizionali di Symfony non sono pratici.

Make è anche molto potente, poiché è possibile eseguire attività in parallelo, evitare di eseguire attività se non sono state apportate modifiche, ecc.

Vamos a ver un ejemplo: el borrado de la caché. Symfony tiene un comando para borrar la caché y otro para pre-generar la caché. Sin embargo, hacer las dos cosas en el mismo proceso no funciona bien porque PHP no es capaz de recargar una clase cuando su contenido cambia. Pero hacerlo con make es facilísmo:

Vediamo un esempio: l’eliminazione della cache. Symfony ha un comando per cancellare la cache e un altro per la pre-generazione della cache. Tuttavia, eseguire entrambi nello stesso processo non funziona bene perché PHP non è in grado di ricaricare una classe quando i suoi contenuti cambiano. Ma farlo con make è facile:

cache-clear:
    @test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/*
.PHONY: cache-clear
 
cache-warmup: cache-clear
    @test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)"
.PHONY: cache-warmup

Un altro esempio pratico: la maggior parte dei miei progetti PHP ha questi due task per eseguire automaticamente i test Blackfire:

bf-dev:
    blackfire-player --endpoint=http://`bin/console server:status --filter=address` run tests/bkf/all.bkf
.PHONY: bf-dev
 
bf-prod:
    blackfire-player --endpoint=https://twig.sensiolabs.org run tests/bkf/all.bkf --variable="env=prod"
.PHONY: bf-prod

Un altro caso di utilizzo di make è quello di mettere un’applicazione in modalità “manutenzione” durante gli aggiornamenti. Molto più comodo di farlo con un comando Symfony.

Gestire gli assets

La versione 3.0 dell’edizione standard Symfony ha rimosso Assetic. Al momento non consigliamo alcun strumento per sostituire Assetic, in quanto il mondo JavaScript è ancora immerso nella ricerca di uno strumento standard per gestire le risorse delle applicazioni web.

Tuttavia, Symfony 4 raccomanderà l’utilizzo di uno strumento e l’integrazione con esso. I dettagli saranno annunciati fra poche settimane. Per ora vogliamo menzionare che in Symfony 4 continuerà ad esistere il comando assets:install per copiare o collegare simbolicamente le risorse dei bundles nella directory pubblica public/bundles/. In Symfony 5 certamente cambieremo tutto questo, dato che non ha molto senso ora che le applicazioni non hanno più bundles.

La implementación de todas estas buenas prácticas supondrá algunos cambios en la estructura de directorios de las aplicaciones Symfony. Y ese será precisamente el tema del próximo artículo. No te lo pierdas.

L’implementazione di tutte queste best practice comporta alcune modifiche alla struttura di directory delle applicazioni Symfony. E sarà proprio l’argomento del prossimo articolo. Non perdertelo.

Questo articolo è una traduzione dell’articolo Symfony 4: Best Practices pubblicato da Fabien Potencier.