Starter-pack per sviluppare in Symfony

Tutto quello che ti serve sapere per sviluppare in Symfony!

Quando sono arrivato in azienda, un po’ di anni fa (un bel po’), già si utilizzava Symfony e per me è stata una bella e traumatica esperienza. La nostra intesa non è stata immediata ma, nonostante le difficolà iniziali, siamo rimasti “amici”. Quando l’ho rivisto, ed era ormai diventato Symfony4 (nel Novembre del 2017), me ne sono innamorato. In questo articolo ti parlerò di quali sono le novità introdotte e il “rething” del framework!

Panoramica

Se utilizzi già Symfony, saprai perfettamente che è un framework PHP, distribuito sotto licenza MIT, che si pone l’obiettivo di aiutare gli sviluppatori a creare applicazioni web in modo semplice e veloce, utilizzando come pattern architetturale l’MVC (Model View Controller).

Se sei un aspirante Symfonyano — e sei alle prime armi — allora ti basta sapere che è un framework, ovvero un “sistema”, che definisce una serie di standard da seguire, implementa una serie di automatismi e fornisce moltissime utilità.

Non preoccuparti però, ci sono anche aspetti negativi!

Innovazione

C’è stato un vero e proprio ripensamento sull’organizzazione del framework, delle sue idee e funzionalità, orientandolo fortemente alla produttività.

Frase tipica di un dirigente medio

Per chi viene da versioni precedenti del framework, c’è bisogno di mettere subito in chiaro una serie di cose che sono mutate o peggio ancora… sparite.

L’organizzazione della nostra applicazione in Bundle, raccomandata precedentemente dai “signori” Symfony, ora è stata eliminata. Sarà che se ne faceva un uso “poco corretto”, come ad esempio creare dei Bundle interdipendenti tra loro e non riutilizzabili in nessun’altra applicazione, ma non mi è dispiaciuto.

I parameters.yml e le sue declinazioni sono sparite a favore delle variabili di ambiente (legati all’infrastruttura) e parametri (legati all’applicazione).

La struttura delle cartelle è diventata meno complessa, uniformandosi ad altri framework.

Leggero

Symfony4 è più “magro”, ovvero sono state eliminate tutte le dipendenze inutili che la maggior parte di noi non avrebbe mai utilizzato per l’intera vita del progetto (fino al 70%).

Se sei uno sviluppatore che diffida dei cambiamenti non temere! Puoi appesantirlo a tuo piacimento, inserendo tutti i pacchetti che ti servono. Ricordati, Symfony è pur sempre flessibile!

Retrocompatibile

I signori Symfony avevano promesso una compatibilità totale per le versioni precedenti, infatti è possibile aggiornare i vecchi progetti 3.x portandoli alla versione 3.4. Da lì possiamo fare un bel salto in avanti fino alla 4. Superfluo dire che non sarà “facile come rubare le caramelle ad un bambino”, ma a nessuno piacciono le cose semplici!

Avremo sicuramente delle deprecazioni da correggere (alcune non obbligatorie), una di queste è la classe che estendono i nostri Controller, deprecata dalla versione 4.2 di Symfony. Ad esempio:

<?php
  namespace App\Controller;
  use Symfony\Bundle\FrameworkBundle\Controller\Controller;
  class DefaultController extends Controller {
    //tanto codice 
  }

bisognerà sostituirla con:

<?php
  namespace App\Controller;
  use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
  class DefaultController extends AbstractController {
    //tanto codice 
  }

Se il progetto è ancora di piccole dimensioni o sei un tipo temerario, allora ti consiglio di sostituire la classe e schedulare un bel giro di test.

Per chiarezza:

Tutti sanno che i Controller non sono altro che classi PHP che ti permettono di leggere delle richieste (REQUEST) e restituire delle risposte (RESPONSE), ma non tutti sanno che le best practices di Symfony affermano che i Controller non devono assolutamente contenere logica di business, ma bensì coordinare i servizi, eventi e/o altro. I servizi sono i preposti a racchiudere queste tipologie di logiche.

Automatico

Molte della azioni che compievamo fino a qualche tempo fa come “automi” (ogni volta!) sono state automatizzate. Tutto ciò è stato possibile grazie a Symfony Flex, un plugin di composer per Symfony, che utilizza delle recipes per impostare e configurare i pacchetti di terze parti, in modo del tutto trasparente allo sviluppatore.

Queste recipes, consultabili sul sito https://flex.symfony.com/, hanno un manifest.json al loro interno che indica a Symfony Flex come installare il pacchetto e configurarlo (file, variabili di ambiente e addirittura cosa inserire nel .gitignore!).

I pacchetti si dividono in official e contrib. Di default SymfonyFlex installerà soltanto le official, ma è possibile installare anche le recipes contrib eseguendo il comando:

composer config extra.symfony.allow-contrib true

Questo comando basterà eseguirlo soltanto la prima volta.

La recipes official sono più affidabili e sono approvate dal Symfony Core Team.

Le recipes contrib sono interamente gestite dalla community e quindi potrebbero anche non essere più mantenute.

Configurazione dell’ambiente

I signori Symfony ci tengono a precisare che ci deve essere una separazione tra le configurazione che riguardano l’infrastruttura da quelle che riguardano l’applicazione.

Legate all’applicazione

Le configurazioni che riguardano l’applicazione possiamo identificarle perché sono quelle che cambiano il comportamento della nostra applicazione, cioè se inviare o meno un’email, se una funzionalità deve essere disponibile o meno, etc.

Queste configurazioni sono definite nella cartella config nei file service.yaml, service_prod.yaml e così via. È necessario creare i file service, relativi agli specifici ambienti, solo se le configurazioni al loro interno variano in base agli ambienti. Le configurazioni del service.yaml sono di default e quindi ereditate da tutti i service. I service specifici per ambiente vanno in sovrascrittura sulle configurazioni di default.

Default:

config/service.yaml

Specifico ambiente:

config/service_<APP_ENV>.yaml

Ci sono delle best practices da tenere conto prima di mettere mano alle configurazioni dei service che riguardano le costanti e i nomi dei parametri.

Le costanti devono essere usate per configurare cose che raramente cambiano e non per configurare cose che non cambieranno mai per l’intera vita del progetto (diventerebbe una lista della spesa altrimenti, no?). Usare le costati all’interno delle classi e non come parametri dei service.

Il nome dei parametri dovrebbe essere il più breve possibile e avere un prefisso che lo identifichi in maniera univoca, così da non farlo andare in conflitto con i bundle di terze parti (es. app.dir piuttosto che dir).

Legate all’infrastruttura

Le configurazioni che riguardano l’infrastruttura, invece, sono quelle che differenziano gli ambienti, ovvero le variabili che cambiano, ad esempio, da dev a prod. Un esempio concreto può essere l’host del database o l’endpoint che stiamo integrando nella nostra applicazione.

Le variabili che utilizziamo devono essere contenute, nella cartella principale del progetto, in un file chiamato .env. Questo file conterrà due cose importanti: l’ambiente che vogliamo utilizzare e le variabili comuni a tutti gli ambienti.

L’ambiente che vogliamo utilizzare è dato dal valore di una variabile presente nel file .env, chiamata APP_ENV. Questa variabile si occuperà di decidere qual è l’ambiente che Symfony dovrà caricare. La regola che applica, anche sui service.yaml, è semplice: caricare il file “.env.<APP_ENV>”.

Tutti questi file necessariamente devono essere messi sotto versioning, ma è possibile gestire delle configurazioni specifiche per determinate macchine. Queste possono leggermente o totalmente differenziare da quelle originali.

Immaginiamo che nasca l’esigenza di sovrascrivere alcuni valori di un’ambiente specifico per una determinata macchina, e non per tutte le altre macchine per cui l’ambiente deve rimanere invariato.

È possibile farlo attraverso il file “.env.<APP_ENV>.local”. In questo modo verrà fatta la sovrascrittura di tutte le variabili comuni presenti nel file “.env.<APP_ENV>”. Così facendo, il nostro file “.env.<APP_ENV>.local” sarà specifico per la macchina e slegato dal versioning.

Le variabili comuni a tutti gli ambienti sono delle variabili che tutte le configurazioni ereditano.

Symfony carica dapprima le variabili contenute nel file .env. Successivamente, rispetto al valore contenuto nella variabile APP_ENV caricherà i relativi ambienti (es. .env.prod).

Se presente anche il file .local (es. .env.prod.local) effettuerà la sovrascrittura del file di environment precedente. Le sovrascritture avvengono in upsert, ovvero se esiste allora viene modificato (update) altrimenti viene aggiunto (insert).

Cablaggio automatico dei servizi

Una delle come migliori di Symfony4 è il cablaggio automatico dei servizi ovvero l’autowiring. Questo è anche abilitato di default!

Quando l’autowiring è abilitato, le istanze di tutte le classi definite all’interno del costruttore o metodo vengono automaticamente passate, senza che lo sviluppatore debba istanziarle. Questo meccanismo automatico avviene solo per gli oggetti (tipizzati) presenti e non per gli altri tipi di variabili come ad esempio stringhe.

Per far si che, ad esempio, un valore di default venga passato sempre alla variabile $pippo è possibile farlo in due modi: definendo il valore di default all’interno della firma del metodo oppure esplicitando il valore come argomento nel file service.yaml.

Symfony non istanzia sempre tutti i servizi, ma soltanto quando sono necessari. Inoltre compila il container, quindi non c’è nessun problema di lentezza. Possono verificarsi problemi di lentezza soltanto in ambiente di sviluppo, data la maggior frequenza di aggiornamento del container.

Per approfondimenti vedi il sito ufficiale: https://symfony.com/doc/current/service_container/autowiring.html

Conclusione

Symfony è un framework in continua evoluzione, tutto da scoprire e piacevole da utilizzare. Ad oggi è arrivato alla versione stabile 5.0, rilasciata il 21 novembre 2019.

Credo (o almeno spero) di averti raccontato il 90% delle cose che ti servono per cominciare ad utilizzare Symfony4!

Che sia per te la prima volta che approcci a Symfony, o addirittura ad un framework PHP, o sia che tu abbia già utilizzato versioni precedenti di Symfony io ti consiglio di usarlo.

Se hai affrontato versioni precedenti che ti hanno scoraggiato per la complessità o per l’onerosità delle cose da fare non preoccuparti, come avrai letto non sarà più necessario. È tutto molto easy!

Se sei ancora indeciso e non vuoi cimentarti su PHP perché non provi a dare un’occhiata a Fastify? Qui puoi trovare un nostro approfondimento.