Symfony 4: installazione e novità della nuova edizione

Il 30 novembre 2017 è stata rilasciata la prima versione stabile della quarta edizione, vedremo come installarla e quali sono le novità

Verso la fine del 2017 è stata rilasciata la prima versione stabile di Symfony 4, perciò è già tempo di aggiornare la vecchia guida per l’installazione del framework e, per essere sempre aggiornati, nei prossimi articoli farò riferimento alla nuova edizione.

Symfony 4 o Symfony 3.4 (con Flex)?

Cominciamo bene: un articolo su Symfony 4 e siamo pure indecisi. Dovessimo iniziare un nuovo progetto, probabilmente non è questo il momento migliore, perché non c’è ancora una LTS (cosa che un po’ mi fa desistere, per non dover fare continui aggiornamenti) e soprattutto perchè l’ecosistema dei bundle (cioè dei package, dei plugin) non è ancora del tutto aggiornato. Tuttavia la versione 3.4 di Symfony con Flex è una LTS ed ha tutte le funzionalità della quarta edizione. Stessa struttura delle directory, stessa logica di funzionamento. L’unica differenza è che Symfony 4 rimuoverà un po’ di codice deprecato, perciò se un bundle non è ancora aggiornato, una web app con Symfony 3.4 continuerà a funzionare (pur segnalando nel logging il codice deprecato), la quarta edizione invece no. Ripeto, Symfony 3.4 ha le stesse caratteristiche della nuova edizione ed è pure una LTS e ora come ora probabilmente conviene cominciare da lì.

Cerco di mantenere i miei articoli sempre aggiornati, tuttavia è bene considerare il “momento storico” in cui vi trovate. Nell’articolo introduttivo mi sono dilungato un pochino di più su come scegliere la versione più conveniente da installare.

Aggiornare PHP

Innanzitutto Symfony 4 richiede almeno PHP 7.1, perciò, se siete rimasti indietro (nonostante PHP sia attualmente alla versione 7.2), è ora di fare un upgrade:

sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.1

Una suite di extension generica può essere la seguente:

sudo apt-get install php7.1-cli php7.1-common php7.1-json php7.1-opcache php7.1-mysql php7.1-mbstring php7.1-mcrypt php7.1-zip php7.1-fpm php7.1-xml

Riavviamo PHP:

sudo service php7.1-fpm restart

Installare Symfony 4

Nella guida alla vecchia edizione, abbiamo conosciuto l’installer symfony, utile per iniziare un nuovo progetto. In Symfony 4 l’installer non esiste più e a dirla tutta viene sconsigliato già dalla v3.4. Basta e avanza il nostro amico Composer:

composer create-project symfony/skeleton my-project

Potete specificare una versione in particolare, ad esempio per utilizzare Symfony 3.4 con Flex digitate:

composer create-project symfony/skeleton my-project "3.4.*"

Il comando di installazione scaricherà tutte le librerie appena necessarie per far funzionare il framework:

Termine dell’installazione di Symfony 4

 

In questo momento abbiamo già un sito funzionante, che possiamo vedere entrando nella directory appena creata e digitando:

php -S 127.0.0.1:8000 -t public

In questo modo abbiamo avviato il webserver interno di PHP (mi raccomando, da non utilizzare in produzione). Se avete mai installato un’edizione precedente di Symfony, potreste storcere un po’ il naso, perché ricorderete che il server si avviava con un elegantissimo e verboso:

bin/console server:run

Il package per fare questa cosa è opzionale e basta aggiungerlo al progetto con Composer:

composer require server --dev

In realtà, ad essere opzionali sono molti package che nelle versioni precedenti venivano installati di default. La ragione è molto semplice. La parola d’ordine col nuovo framework è flessibilità. Vale a dire che SF4 è stato pensato per poter essere un framework molto potente, oppure un micro-framework snello ed efficace. Perciò è chiaro che tutto ciò che è superfluo viene eliminato, tant’è che una nuova installazione contiene il 70% di codice in meno rispetto a Symfony 3. C’è solo lo stretto indispensabile per far galleggiare la barca. E lasciatemelo dire, adoro questa filosofia.

L’uscita di Symfony 4 praticamente coincide con l’elogio funebre di Silex, il micro-framework basato sui Symfony Components, che a questo punto non ha più senso di esistere. Inoltre, pensate a chi si avvicina per la prima volta ad un framework PHP. Può cominciare con qualcosa di piccolo e man mano che la confidenza aumenta può aggiungere nuovi elementi al progetto, fino ad arrivare alla versione “Super Sayan”, senza dover rifare tutto da capo. L’esperienza didattica ne giova parecchio e sono sicuro che il successo di Symfony dipenderà anche da questo.

Torniamo a noi. Dopo aver avviato il server, con il browser andiamo su http://127.0.0.1:8000 e vedremo qualcosa del genere:

A differenza delle edizioni precedenti, il file che renderizza questa schermata è da qualche parte nei vendor, cioè tra le dipendenze, che non dobbiamo toccare. Questo vale a dire che abbiamo un progetto nuovo di zecca e ready-to-use.

Come dicevamo poco fa, sono molti i package che mancano e che prima trovavamo di default, come Twig e Doctrine, che vedremo tra un attimo. Gestire questi package è semplicissimo grazie ad un’importante novità: Flex. Si tratta di un plugin di Composer che permette principalmente di fare due cose:

  • Rendere le installazioni più friendly, attraverso gli alias;
  • Abilitare e preconfigurare i package;

Package più importanti

Se avete già utilizzato un’edizione precedente di Symfony, conoscerete bene il sistema dei bundle, concettualmente molto simili a dei plugin. In Symfony 4 il concetto di bundle un po’ svanisce e si parla di package. Ce ne sono alcuni che ritengo fondamentali, perché cambiano totalmente l’esperienza di sviluppo. Vediamone alcuni e come installarli:

Profiler

Dove saremmo senza questo componente? Si tratta di una toolbar da utilizzare in modalità di sviluppo, la quale ci dà importanti indicazioni sulla salute della nostra webapp, come il tempo di esecuzione della richiesta, il contenuto di una richiesta e della relativa risposta, il numero e il tempo di esecuzione delle query in quella pagina e così via. Assolutamente immancabile, perciò eseguiamo subito:

composer require profiler

Twig

Twig è un template engine molto potente, grazie al concetto di eredità e di inclusione dei template e trovo anche questo package immancabile, specie in progetti con serverside rendering (altrimenti si presuppone che ci sia una gestione dei template lato front-end, ma varia di caso in caso). A dirla tutta, Twig è una dipendenza di Profiler, perciò, se abbiamo già installato il componente precedente, abbiamo già Twig, altrimenti questo è il comando per l’installazione:

composer require twig

Doctrine

Doctrine è un ORM (Object-Relational Mapping) PHP. In pratica consente di mappare un database in una collezione di oggetti, e di trattare le informazioni come tali. Non ragioneremo più in termini di tabelle, righe e colonne, ma in termini di oggetti, linkati tra di loro. È interessante sapere che si adatta al DBMS che utilizziamo, quindi può essere utilizzato con MySql, PostgreSQL, MongoDB.

composer require doctrine

Annotation

Le annotation sono delle metadata (cioè delle informazioni) embeddate nei commenti formattati in un certo modo. Esempi tipici possono riguardare la rotta (cioè l’URL) da seguire, o il template da renderizzare. Non si tratta di un package immancabile come gli altri, c’è chi li ama e chi li detesta. Si portano dietro una serie di vantaggi e svantaggi, da considerare soprattutto in ambito di manutenibilità e capita che perfino Symfony, nella documentazione, ne sconsigli l’utilizzo. D’altra parte possono essere molto comode in alcuni contesti. A voler essere brevi, tutto sta nel valutare se è meglio avere un’organizzazione dei metadati centralizzata o distribuita. Lascio a voi approfondire, nel caso questo è il comando per l’installazione:

composer require annotation

Security

Inserirei anche questo package tra gli immancabili, perché aiuta a gestire due aspetti fondamentali della cyber security: authentication e authorization. Cioè aiuta a stabilire chi può accedere alla web app e chi può eseguire una determinata azione.

composer require security

A questo punto dovreste avere una base piuttosto comune, ma chiaramente varia di caso in caso. È da notare che nelle scorse edizioni, a questo punto, avevamo ancora da configurare tutti i package, aggiungendo il setup in un file di configurazione globale e dichiarando esplicitamente il package installato al kernel. Grazie a Flex, invece, tutto questo avviene in automatico e siamo già pronti per sporcarci le mani sul serio.

L'autore

Ciao, sono Antonio D'Amore, e sono un ingegnere informatico con la forte passione per il web. Sguazzo nell'ambiente startup, grazie a Tobevy, di cui sono co-founder e CTO, e adoro la divulgazione, ragion per cui ho creato questo blog