Symfony 4 : un état des lieux avant la sortie

13/11/2017 ·  web

La sortie de Symfony 4 approche à grand pas et est prévue pour fin Novembre (Yes!).

Nous vous proposons de faire un dernier tour du propriétaire, plus complet que notre précédent article, suite à l'annonce de la mise à disposition de Symfony Beta 4, dernière étape avant la sortie officielle de Symfony 4.0 stable.

Etat d'avancement Symfony 4.0

Cette présentation a pour objectif de faire une cartographie macroscopique des nouveautés introduites par cette version majeure.

Un micro framework par défaut

Symfony 4 introduit un changement de philosophie et propose désormais aux développeurs de pouvoir utiliser et installer uniquement les composants qui lui sont strictement nécessaires.

La nouvelle édition standard de symfony ne contient désormais que le core du framework qu'on pourrait apparenter à un micro framework. Comme vous pouvez le constater dans la capture ci-dessous d'une installation Symfony 4 standard, on retrouve le strict nécessaire.

Installation symfony 4

Vous remarquerez entre autre la disparition de Doctrine, Twig, ... dans le socle. On verra un peu plus loin qu'ils restent tout de même disponible.

Des changements dans l'arborescence des dossiers

Après avoir déjà eu le droit à un remaniement de la structure des dossiers pour les précédentes versions majeures de Symfony, SF 4 apporte aussi plusieurs modifications à ce sujet. Comme vous pouvez le remarquer dans la capture d'écran ci-dessous:

  • Suppression du dossier web remplacé par un dossier public
  • Disparition du dossier app
  • Un dossier config à la racine fait son apparition et contient l'ensemble des configurations de votre projet par packages
  • Une arborescence beaucoup plus "plate"

Nouvelle architecture des dossiers Symfony 4

Pour les développeurs familiers avec la structure de dossier de Symfony 3, vous remarquerez de nombreux autres changements (déplacement de Kernel.php, modification de app.php en index.php etc...).

12 factor app

De nos jours, les applications sont bien souvent proposées avec des structures "As A Service". Le 12 factor app est une méthodologie pour créer des applications de ce type. Pour en savoir plus n'hésitez pas a lire la présentation en 12 chapitres de cette méthodologie sur le site officiel.

Dans les grandes lignes on peut retenir plusieurs objectifs:

  • Maximiser la portabilité de l'application en s'appuyant le moins possible sur des dépendances du système d'exploitation
  • Être compatible avec les plateformes de déploiements modernes (Cloud, Paas, ...)
  • Minimiser les différences entre les plateformes de production et développement et ainsi faciliter la mise en place du déploiement continu
  • Permettre le scaling de l'application sans avoir besoin de réaliser de grands changements dans l'application

Symfony 4 essaie de répondre au mieux à ces différentes problématiques.

Symfony Flex et les recettes

Symfony 4 introduit l'arrivée de Symfony Flex le nouvel installateur officiel du framework. Il remplace donc l'ancien installateur de Symfony standard édition et est d'ores et déjà compatible avec Symfony 3.3.

Symfony Flex n'est pas une nouvelle version de Symfony, mais bel et bien un outil à part entière.

Symfony Flex améliore sensiblement les processus d'installation dans Symfony et automatise les tâches (rébarbatives) comme installer ou désinstaller les bundles et la gestion de Composer. Flex apporte notamment la possibilité d'exécuter et automatiser des tâches avant et après l'exécution d'une tâche Composer. Ainsi Flex apporte la possibilité, en plus de la gestion de l'installation des librairies et bundles, de pouvoir les configurer automatiquement.

L'ensemble de ces tâches et fonctionnalités sont décrits sous forme de recette. Vous pouvez par exemple retrouver l'ensemble des recettes symfony pour les paquets Composer gérés par l'équipe en charge du Core de Symfony comme:

  • API platform
  • Security
  • Doctrine
  • Easy Admin
  • Twig
  • ...

Lien vers le dépôt officiel.

Les packages officiels

Avec cette nouvelle version de Symfony, de nombreux bundles sont désormais référencés sur les serveurs de Symfony Flex, leur donnant un caractère plus officiel dans l'écosystème Symfony.

EasyAdminBundle

Si vous avez besoin de développer une interface d'administration pour votre site, EasyAdminBundle vous facilitera grandement la vie. Il permet, depuis un simple fichier de configuration, de générer les pages de CRUD (Create / Read / Update / Delete) de vos objets, avec un moteur de recherche et une gestion de la pagination et du tri. Le tout dans une interface responsive pour s'adapter à tous vos supports !

Page générée par EasyAdmin

Doctrine

Doctrine reste bien sûr l'ORM privilégié sous Symfony 4. Toujours bien interfacé avec Symfony, il vous permettra d'interagir facilement avec votre base de données.

APIPlatform

APIPlatform est un framework construit avec Symfony et conçu pour faciliter le développement d'API REST ou GraphQL.

Et bien d'autres !

Vous pourrez trouver la liste des recipes de Symfony Flex sur le Symfony Recipes Server.

Les contrôleurs

Si vous avez l'habitude de travailler avec Symfony 2 ou Symfony 3 jusqu'à sa version 3.2, vous vous êtes peut-être déjà retrouvé coincé dans une situation où vous vous êtes demandé :

Est-ce que je peux définir mon contrôleur en tant que service ?

Et si c'est le cas, vous avez aussi sûrement vu cet avertissement dans la documentation de Symfony :

Avertissement Symfony

Dans cette nouvelle version de Symfony, non seulement définir les contrôleurs en tant que service n'est plus considéré comme une mauvaise pratique, mais les contrôleurs sont des services par défaut !

Vous pouvez donc intéragir facilement avec eux depuis d'autres services, et donc d'autres contrôleurs.

L'injection de dépendance automatique: Autowiring

Qu'est-ce que c'est ?

Cette fonctionnalité présente depuis la version 2.8 de Symfony, repensé dans la version 3.3 est maintenant activé par défaut. Concrètement, il n'est plus nécessaire de préciser dans la configuration les dépendances de vos services.

Comment l'autowiring fonctionne ?

Prenons une première classe ci-dessous avec une dépendance.

  namespace AppBundle\Service;
  
  use AppBundle\Service\Categorie;

  class Produit
  {
      private $categorie;
  
      public function __construct(Categorie $categorie)
      {
          $this->categorie = $categorie;
      }
  }

Et ci-dessous la classe des catégories
namespace AppBundle\Service;

  class Categorie
  {
      private $name;
  
      public function getName()
      {
          return $this->name;
      }
  }

La configuration par défaut de Symfony 4 va permettre à ces deux classes d'être automatiquement enregistrées en tant que service et d'être liées selon leurs dépendances.

Le système d'autowiring va utiliser le type du paramètre indiqué dans le constructeur de la classe Produit (ou dans n'importe quelle autre méthode) et cherche un service avec un ID qui correspond parfaitement à ce dernier.

Trois cas sont possibles :

  • Si aucun service n'a été défini pour ce type et si le type correspond à une classe non abstraite, alors la classe sera enregistrée automatiquement en tant que service privé, et celui-ci sera utilisé comme argument.
  • Si un service défini dans le container correspond au type, alors un alias est créé pour ce service et l'autowiring fonctionne de façon standard avec celui-ci
  • Si deux services ou plus correspondent alors une exception est levée. Il sera alors nécessaire de créer un alias pour le service à utiliser ou alors de l'indiquer de façon explicite dans la configuration.

En résumé

L'exemple ci-dessus se voulait simple, avec seulement deux classes, mais dans un contexte différent avec un grand nombre de dépendances et des dizaines de services, l'intérêt de l'autowiring est indéniable. Dans tous les cas c'est une évolution très agréable pour les développeurs.

On notera que l'autowiring ne fonctionne pas par magie, et l'équipe de Symfony l'a imaginé de façon à ce que son comportement reste prévisible.

Webpack Encore

Webpack Encore

Dans "Webpack Encore" il y a "Webpack"

Initialement utilisé par la communauté REACT, Webpack est rapidement devenu un nouveau standard de l'industrie Web pour gérer les assets du front-end.

Les outils qui étaient précédemment largement utilisés dans ce domaines, les task-runners tels que Grunt et Gulp, nécessitaient une lourde configuration, qui devait être modifiée à chaque nouveau fichier ou lors de changements dans l'organisation du code JavaScript et CSS. La plupart du temps, ces outils étaient utilisés pour produire un fichier JS minifié et un fichier CSS minifié, utilisés sur l'ensemble des pages du site. Pour ce faire, leurs fichiers de configuration listaient l'ensemble des assets à faire traiter par différents processus (transpile, concat, minimify, ...).

Webpack se différencie de ces outils par son approche plus modulaire. Le fichier de configuration de Webpack va, pour chaque module, pointé vers un "point d'entrée", qui est un fichier JS. Ce dernier va ensuite inclure les autres fichiers nécessaires (JS, CSS, images) via des directives "require" ou "import". En bout de chaîne Webpack va "traiter" tous ces fichiers hétérogènes pour sortir du code ou des assets compréhensibles par le navigateur.

Webpack permet donc de générer pour chaque page des assets optimisés, ne contenant que le strict nécessaire à son bon fonctionnement. La configuration de l'outil peut sembler complexe, mais présente l'avantage de ne nécessiter que peu de modification durant l'évolution des projets, puisque les dépendances sont gérés directement dans le code et non dans la configuration.

Pour plus d'informations sur webpack vous pouvez suivre ce lien

Une configuration fastidieuse malgré tous ses atouts

Si sur le papier Webpack propose une réelle avancée par rapport aux "task-runners" Grunt & Gulp, sa configuration n'en est pas moins fastidieuse et beaucoup de développeurs rechignent encore à sauter le pas face à cette difficulté.

C'est en partant de ce constat que les équipes de SensioLabs on développé "Webpack Encore", un webpack facile à utiliser et spécialement optimisé pour fonctionner avec Symfony (même si il peut aussi ête utilisé en dehors).

La meilleur librairie accessible à tous avec Webpack Encore

Inspiré de "Webpacker" et "Mix", "Webpack Encore" met la configuration à la portée de tous tout en étant spécialement optimisé pour fonctionner avec Symfony 4.

Voila qui devrait lever les dernières réticences à son utilisation et permettra une utilisation avancée des assets dans Symfony.

L'avis d'Integral Service

Symfony 4 performance, qualité et simplicité

Nous utilisons Symfony dans de nombreux projets d'applications Web qui nécessitent une architecture robuste, évolutive et professionnelle.

Symfony 4 est la suite logique aux évolutions successives du framework. Cette version est orientée performance en proposant un framework standard minimaliste sur lequel on peut greffer uniquement les bundles ou librairies qui sont nécessaires.

Cette version est aussi rafraichissante pour les développeurs car une bonne partie du travail qui était rébarbatif et apportait peut de valeur ajoutée dans les précédentes versions a été automatisé ou simplifié.

Ce nouvel opus reste droit dans ses bottes et propose des nouveautés qui améliore encore la qualité de ce framework et confirme sa place dans les frameworks PHP professionnels.

En attendant Symfony 4

En attendant la sortie officielle, nous vous proposons une série de petits tutoriels ou démonstrations pour vous initier à cette nouvelle version.