Symfony 4: Micro applicazioni e monoliti

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)

Uno dei dibattiti più intensi nel mondo della programmazione è legato alle applicazioni “monolite” contro micro-applicazioni o micro-servizi. Nel progetto Symfony riteniamo che i due modi per sviluppare le applicazioni siano corretti (a seconda delle circostanze) ed è per questo che Symfony supporta entrambi.

La versione “Symfony Standard Edition” può essere pensata per sviluppare monoliti, già che il pacchetto symfony / symfony è una delle sue dipendenze. Questo pacchetto è in realtà un “meta-package” che installa tutti i componenti Symfony e alcuni dei bundles considerati come “core”. Tra l’altro, questo pacchetto installa per esempio il supporto per Twig e anche il profiler. Ma se per esempio si stai sviluppando l’API della tua nuova applicazione mobile, non ne hai bisogno.

Ovviamente tenere nella directory vendor/ alcuni archivi in più che non si utilizzano non è un problema così grave. Alcuni programmatori ritengono tuttavia che le loro applicazioni siano sovradimensionate a causa di quei pochi archivi aggiuntivi. In ogni caso, questa è più una percezione che una realtà.

Il microframework Silex propone un modo molto diverso di lavorare in cui ogni componente utilizzato viene esplicitamente caricato. Significa che Silex è più semplice, più leggero o più veloce di Symfony? No. Eppure, Symfony 4 apparirà come Silex in questo modo di lavorare.

Applicazioni Symfony minimaliste

È la fine dell’utilizzo della dipendenza symfony/symfony. Le applicazioni Symfony ora richiederanno ogni componente e ogni bundle da utilizzare. Questa è probabilmente la più importante modifica che si noterà durante lo sviluppo di applicazioni con Symfony 4. Tuttavia, questa modifica non è stata fatta in modo che nella directory vendor/ ci siano meno archivi. In realtà, questo cambiamento apre la porta a un mondo intero di nuove possibilità.

Per cominciare, consentirà la configurazione automatica della dipendenze, che sarà una dei punti forti di Symfony 4. Quando si installa un bundle, Symfony lo configurerà automaticamente con una configurazione predefinita appropriata. E questa configurazione si adatterà dinamicamente a seconda delle altre possibili dipendenze che hai installato nell’applicazione.

Considerate ad esempio il caso di FrameworkBundle. Alcune delle sue funzioni, quali i formulari, la validazione, i modelli, gli assets, il serializzatore, ecc. potranno essere attivate o disattivate.

In Symfony 3.2 i formulari sono vengono attivate per impostazione predefinita, anche se è possibile disattivarle se non le si utilizzeranno nell’applicazione. Perché i formulari sono attivati per impostazione predefinita? Perché Symfony non ha modo di sapere se si utilizzeranno i moduli nell’applicazione o no. Disattivandoli per impostazione predefinita renderebbe peggiore l’esperienza di utilizzo, perché sarebbe un’altra opzione da studiare e configurare prima di poter testare la tua primo formulario.

Ora immaginate di avere un’applicazione che non dipenda da symfony/symfony ma semplicemente da symfony/framework-bundle. Attivare/disattivare automaticamente il supporto di moduli è ormai possibile. Se l’applicazione installa symfony/form, attiva il supporto ai modulo. Se no, lo disattiva. Una soluzione semplice, che non richiede alcuna magia e non richiede alcuna configurazione. Un’esperienza di utilizzo incredibile che ti farà innamore di Symfony 4.

Una delle conseguenze di questo nuovo comportamento è che anche la prestazione migliora in modo significativo, poiché tutte le funzionalità che non si utilizzano sono disattivate. Senza dover toccare niente o ottimizzare alcun file di configurazione. Ma parleremo dei benchmark delle prestazioni in un altro articolo.

Il nuovo minimalismo di Symfony vi obbliga a prendere decisioni riguardo all’applicazione e all’ambiente in cui viene eseguito. Ad esempio, oltre a eliminare i file LICENSE e README nella struttura predefinita di nuove applicazioni, non ci saranno neanche file .htaccess. Cosa succede se utilizzi Apache nel progetto? Non preoccuparti, perché in un altro articolo proporremo un’altra soluzione.

Composizione

La rimozione della dipendenza symfony/symfony consente inoltre di implementare altre funzionalità essenziali di Symfony 4: la scoperta automatica della dipendenza e la cancellazione delle dipendenze. Nell’articolo precedente abbiamo citato il tema della “composizione” anziché “eredità”. Symfony 4 sfrutterà la riduzione delle dipendenze per utilizzare “composizione” nelle tue applicazioni.

Vuoi utilizzare i formulari? Allora installa la dipendenza di symfony/form. Vuoi utilizzare il server web che integrato in PHP per impostazione predefinita? È possibile installare la dipendenza di symfony/web-server-bundle. Le applicazioni di Symfony migliorano progressivamente, aggiungendo le dipendenze necessarie.

Se si aggiunge a tutto ciò la configurazione automatica, il risultato è veramente interessante. Non hai più bisogno del server web interno PHP? Allora rimuovi il pacchetto symfony/web-server-bundle e Symfony si occuperà di “de-configura” il pacchetto per te (rimuoverlo da AppKernel, eliminare la sua configurazione, ecc.)

Un altro buon esempio della modifica introdotta da questo nuovo paradigma è il bundle SensioDistributionBundle che viene installato automaticamente quando si utilizza “Symfony Standard Edition”.

Quando viene pubblicata una nuova versione del bundle, alcuni dei suoi archivi vengono copiati direttamente nell’edizione standard Symfony. Quindi è necessario eliminare tutti quei files non più necessari e che potrebbero essere potenzialmente pericolosi sul server di produzione, come per esempio web/config.php. Non pensi che sia un modo strano di fare le cose?

A nostro parere sì; quindi abbiamo spostato tutta questa logica in un nuovo pacchetto chiamato symfony/requirements-checker. Vuoi controllare se il computer è pronto per eseguire applicazioni Symfony? 1) Installa questo pacchetto con Composer; 2) esegui i suoi script; 3) correggi eventuali errori segnalati; 4) Disinstalla il pacchetto. Fatto. Hai verificato i requisiti e non hai lasciato traccia nell’applicazione, ne hai dovuto configurare o toccare nulla.

L’altra funzionalità di SensioDistributionBundle è quella di eseguire alcuni script ogni volta che si esegue composer install o composer update. Ad esempio, per creare il file bootstrap.php (che non è più necessario se si utilizza PHP 7), eliminare la cache, installare gli assets ecc. Questi script vengono eseguiti chiamando Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::* nel file composer.json. Di nuovo, non sembra il modo giusto di fare le cose. Quindi, in Symfony 4 abbiamo riscritto completamente questo processo in modo più flessibile. Ora puoi anche aggiungere automaticamente i tuoi script a Composer.

Quindi non pubblicheremo nessuna versione di SensioDistributionBundle compatibile con Symfony 4. Non ce n’è più bisogno. Pensate a “Symfony Flex” come una versione migliorata, più moderna e più potente di SensioDistributionBundle.

Addio ai bundle nella tua applicazione

Quando abbiamo pubblicato la prima versione del documento di Buone Pratiche Ufficiali di Symfony, abbiamo discusso come promuovere applicazioni senza bundle o con un unico bundle. Alla fine abbiamo deciso di consigliare l’utilizzo di un singolo bundle denominato AppBundle per non fare cambiamenti troppo drastici. Inoltre, in quel momento Symfony non era pronta per creare applicazioni senza bundle in modo semplice. Ma tutto questo è cambiato perché negli ultimi mesi abbiamo fatto molte modifiche per assicurare che sia facile creare applicazioni senza bundle in Symfony 4.

Quindi Symfony 4 non solo genererà applicazioni senza pacchetti, ma raccomanderà anche di non creare bundle nelle vostre applicazioni. Il codice dell’applicazione non sarà più raggruppato in un bundle chiamato AppBundle ma alla directory src della tua applicazione sotto lo spazio dei nomi App/. Ancora una volta, questo cambiamento riduce la complessità percepita dai programmatori e provoca il disaccoppiamento del codice da Symfony. Personalmente non crediamo che le applicazioni debbano essere disaccoppiate al 100% dal framework che usano (sia quel che sia), ma da Symfony 3.3 stiamo facendo sempre più modifiche per consentirti di farlo se è quello che vuoi.

Le applicazioni senza bundle sono una delle tante nuove buone pratiche proposte per Symfony 4. E le buone pratiche saranno oggetto del prossimo articolo.

Questo articolo è una traduzione dell’articolo Symfony 4: Monolith vs Micro pubblicato da Fabien Potencier.