Feedback Symfony Live 2018

Actualité ekino -

Article paru le :
Article paru le :

(coécrit par Gabriel Soullier)

Le “Symfony Live” est depuis quelques années un des grands moments de la communauté PHP Symfony et son écosystème. C’est l’occasion pour les différents acteurs de se retrouver, d’échanger, mais surtout dévoiler les nouveautés. Pour le dixième anniversaire, l’équipe d’ekino s’est rendue à la Cité Universitaire de Paris les 29 et 30 mars derniers pour prendre part à la cérémonie.

Symfony 4

Après un joli message de bienvenue devant devant une salle comble, des nouveautés sur Symfony ont été révélées.

Fabien Potencier avait lui même, lors de la précédente édition dans une keynote, annoncé Symfony 4. Cette édition a été l’occasion de dévoiler cette nouvelle version de Symfony qui est en terme de structure de fichiers un véritable “breaking change”.

Pendant 45 minutes, il a expliqué la nouvelle architecture de Symfony plus souple et complètement “bundle-less”. Les nouveaux composants comme flex (un plugin Composer), maker (une alternative au SensioGeneratorBundle), Prefetch maker (facilite l’installation), Manifest (permet de définir ce que flex doit faire) font de Symfony 4 une version plus riche en expérience développeur et beaucoup plus performante.

Vers la fin de son speech, il a évoqué l’avenir de Silex qui selon lui, en l’absence de contributeurs, ne devrait plus être maintenu. Voici un article à ce sujet silex what next.

Architecture Modulaire grâce à Symfony et l’écosystème open source

Marc Weistroff sur la base des dernières versions de Symfony et la maturité de l’écosystème open source permettant de réaliser des architectures modulaires de grande qualité, avec des paradigmes de développement différents, a brillamment présenté un moyen de créer des systèmes modulaires complets. Il a utilisé AudienceHero pour expliquer comment tirer profit des meilleures briques logicielles (Autoconfiguration, Autowiring, Api Platform, React Admin, etc.) afin de créer des systèmes modulaires.

Traduire efficacement une application Symfony

Mathieu Santostefano, nous a offert une très belle présentation sur un sujet récurrent dans les projets d’ordre international et pas souvent facile à gérer. Après avoir rappelé les keywords concernant la traduction notamment I18n, le format xliff, il a brillamment démontré comment faire travailler efficacement tous les acteurs (développeurs, traducteurs, intervenant externes), et garder l’intégrité des traductions de l’application. Il a aussi mis l’accent sur l’intérêt de toujours inclure une traduction dans son architecture même si le besoin n’est pas exprimé au départ, c’est toujours une “best practice”.

Après cette présentation j’avais qu’une envie : mettre à jour tous mes projets.

Migration en Symfony 4 de l’API de connexion Allociné, dans un écosystème en 3.3/3.4

Estelle Le Cam dans un brillant exposé, nous a présenté de façon détaillée le processus qu’elle a mis en oeuvre pour arriver à migrer son application vers Symfony 4. On a pu s’apercevoir des pièges qui peuvent subsister lors de processus, notamment le changement de structure de fichiers, d’extension de fichiers (yml en yaml).

Quels outils pour améliorer la vie des développeurs Symfony ?

Romain Gautier, nous a présenté son feedback sur ses dernières années de développement chez SensioLabs notamment sur les outils indispensables dans le quotidien d’un développeur Symfony. Très belle présentation, il a démontré avec efficacité l’intérêt de tous les outils présentés :

  • Doctrine Migrations : permet de gérer les évolutions des différents schémas de la base de données tout au long du projet
  • Fixtures : met à disposition des données de tests
  • Docker : facilite la mise en place des environnements de travail
  • Git : pour le versionning et le déploiement
  • GitLab CI : simplifie l’intégration continue en utilisant des images Docker.

J’étais super heureux de constater que chez ekino on utilise les mêmes outils et “best practices”.

Zoom sur la “Clean Architecture” en Symfony chez Openclassrooms

Kuzniak Romain, dans un brillant exposé, a présenté un exemple d’application sous Symfony et les différentes implémentations possibles dans différents types d’architectures (MVC, Service Layer, DDD) et comment la “Clean Architecture” est utilisée chez OpenClassrooms depuis plusieurs années. Il a aussi relaté que ce modèle d’architecture reste encore un peu abstraite dans la mesure où il y a très peu de documentation, ce qui rend aussi la montée en compétence difficile (entre 3 et 6 mois).

Testez vos tests en introduisant des bugs avec le mutation Testing

Théo Fidry nous a présenté le principe du Mutation Testing. Une très belle présentation dans laquelle il explique comment qualifier la robustesse de nos tests unitaires et ainsi aller plus loin dans l’écriture de tests. L’objectif du Mutation Testing est d’introduire des “mutants” c’est-à-dire des modifications mineures du code source afin d’éprouver nos suites de tests. Dans ses exemples le résultat était juste fabuleux. Je crois que toute l’assemblée avait juste hâte de tester sur place. Toutefois petite précaution, introduire du code “mutants”, c’est bien, mais on peut très vite doubler nos cas de tests.

Ne soyez plus l’esclave de Doctrine

Derrière ce titre accrocheur, Grégoire Paris et Maxime Vebert n’ont absolument pas “critiqué” Doctrine mais orienté celui-ci vers une approche plus orientée métier.
Ainsi ils nous ont livré des “tips & tricks” afin d’utiliser la puissance de l’ORM dans un contexte DDD (Domain Driven Design).

Un talk très enrichissant mais pas forcément facile à appréhender.

Tirer le maximum du moteur PHP 7 – l’exemple de Symfony

On commence fort la 2e journée par une immersion dans les entrailles de la gestion mémoire de PHP. Nicolas Grekas nous fait partager son retour d’expérience sur l’optimisation des performances de Symfony 4.

Car pour tirer l’efficacité maximum du code existant il a fallu aller au delà de la “simple“ (et c’est déjà bien) optimisation algorithmique et jouer sur la mémoire interne du langage.

Ci dessous un exemple bluffant sur cette méthode du container qui est appelée pour chaque valeur lors de la compilation du container

Une simple \ ajouté devant la méthode is_array a permit d’obtenir un gain de temps d’exécution de 783ms ! En effet en indiquant à PHP d’utiliser la fonction native is_array on économise un appel opcode à cette fonction. Gain infime unitairement mais significatif sur plusieurs milliers (millions ?) d’appels consécutifs.

Bien évidemment les techniques démontrées lors de la présentation sont à appliquer uniquement aux endroits clés de l’application sous peine de perdre beaucoup de temps pour un gain de performance quasi indétectable. Des outils d’analyse de code (dans l’exemple Blackfire) sont fortement recommandés pour identifier le code où il est pertinent de se livrer à ce type d’optimisations.

Symfony Messenger : Queues, workers et bien plus encore !

C’était une demande de la communauté et Samuel Roze l’a entendue : un composant messenger expérimental à partir Symfony 4.1 pour gérer l’envoi de message via file d’attente.

Le composant Symfony de base offre une implémentation des concepts suivants :

  • Message : n’importe quelle entité serializable
  • Sender : serialize un message et l’envoi
  • Receiver : deserialize un message et le transfert vers un handler
  • Handler : contient la logique métier, n’importe quel type callable PHP
  • Bus : route les messages à travers une succession de middleware

Sur Symfony, les middlewares suivants sont disponibles : 

  • LoggingMiddleware : log le traitement des messages
  • SendMessageMiddleware : transmet les messages à un tiers (message broker ou api par exemple) pour une gestion asynchrone
  • HandleMessageMiddleware : transmet les messages au handler adapté

Le cas d’usage le plus courant pour le traitement asynchrone des messages est de les envoyer à un broker comme RabbitMQ, cette responsabilité a été déléguée à la librairie enqueue car elle possède déjà une liste exhaustive d’adaptateurs (AMQP, Kafka, Redis, Amazon SQS pour en citer quelques-uns).

PR de la documentation officielle

Utilisation de HTTPlug Bundle en environnement de test

Une présentation par Gary Pegeot sur l’utilisation de HTTPlug pour faciliter les tests avec des clients HTTP en les découplant de la logique métier.

Il y a beaucoup d’exemples concrets de code sur ce sujet alors je vous invite à consulter les slides pour plus d’informations.

REST ou GraphQL ? Exemples illustrés avec Symfony et API Platform

Kevin Dunglas aborde le vaste sujet du meilleur format d’API fort de son expérience dans le création d’API platform.

La présentation démarre par les fonctionnalités qu’offre API platform. On notera surtout qu’il ne s’agit pas que d’une solution clé en main pour exposer son API mais bien de couvrir tous les besoins qui existent autour d’une API du modèle jusqu’au déploiement dans le cloud. On pense à des besoins tels que génération du CRUD, génération de la documentation, gestion de l’authentification, génération d’admin en React ou Vue ou encore intégration avec Kubernetes. Tout ceci est obtenu uniquement à partir de la déclaration du modèle alors on comprend mieux le terme de platform !

Par la suite, Kevin a présenté les différents formats supportés par API platform ce qui l’amène à comparer les avantages et les inconvénients des deux principaux standards actuels REST et GraphQL.

La présentation fut, sujet oblige, complexe, mais très intéressante et très animée, on voit que l’orateur maîtrise son sujet dans les moindres détails.

En résumé les éléments importants à avoir en tête lorsque l’on hésite entre les deux.

GraphQL

Avantages : idéal pour récupérer des données de manière dynamique ou si l’api est consommée par de nombreux et différents clients et permet de récupérer des données non liées à l’objet principal facilement.

Inconvénients : peu de compatibilité avec le protocole HTTP (cache, logs, négociation de contenu) et il est plus difficile d’implémenter certains aspects applicatifs comme le cache (encore), le parsing, la sécurité. Performance inférieures à REST.

REST

Avantages : Solution mature et robuste qui éxploite tous les avantages du protocole HTTP et peut fournir des fonctions similaires à GraphQL dans sa version “moderne” (sparse fieldsets, batch endpoints). 

Inconvénients : pas de contre indication d’après l’auteur !

 

Pour concilier les deux, Kevin suggère de privilégier GraphQL pour les API privées consommées par des clients dynamiques et REST pour les API publiques.

Développez votre frontend avec ReactJS et Symfony Webpack Encore

Certainement la présentation la plus front end présentée par Alain Hippolyte pour introduire les développeurs backend au JS moderne. Il nous présente Webpack Encore : une librairie destinée à simplifier la configuration de Webpack sur votre projet.

On commence par une comparaison entre un code JavaScript “legacy” et sa version moderne (ES6) pour donner envie et, il n’y a pas photo, c’est beaucoup mieux.

Malheureusement les navigateurs ne vont pas aussi vite que la communauté et il faut “transpiler” (comprendre traduire) ce code moderne en code legacy avant de l’intégrer au projet. C’est là qu’intervient Webpack.

Ensuite, après une rapide présentation de ses capacités, Alain compare une configuration Webpack classique avec sa version Webpack Encore qui s’avère nettement plus succincte.

En conclusion, Webpack Encore est un gain de temps et de lisibilité précieux si vous ne voulez pas investir trop de temps dans la documentation de Webpack pour vous concentrer sur le code. Par exemple pour activer le support de sass sur votre projet il suffit d’un simple appel à la fonction enableSassLoader(), idem pour React ou Jquery.

 

À chacun de choisir entre cette approche et un contrôle plus fin mais au détriment d’une configuration plus lourde. Dans tous les cas, il faut surtout retenir que Webpack est LA solution de la communauté pour la gestion des assets.

Le composant workflow de Symfony, c’est graphement bien !

La dernière présentation de la journée a porté sur le composant workflow qui fait son apparition avec Symfony 3.2 et qui nous est présenté par Hamza Amrouche suite à son utilisation sur un projet client. 

Ce dernier permet d’abstraire la gestion d’états (ou places) et leurs transitions.

Il suffit de définir ces derniers dans votre configuration comme le montre l’exemple d’un workflow classique de publication d’un article de blog (comme celui-ci)

 

Vous pourrez utiliser le service (ici workflow.blog_publishing) qui sera créé à partir de cette configuration pour poser des questions existentielles : “quel est le statut de ce post ?”, “quel statut puis-je lui affecter ?” ou plus précisément “puis-je publier ce post ?”, de plus ces fonctions sont disponibles en extensions Twig.

Par ailleurs, un système d’événements complet est mis à disposition si la décision à prendre pour un changement d’état est complexe ou si vous devez ajouter une logique métier à un moment du cycle de vie du workflow.

Cela peut paraître trivial à programmer sur un un workflow simple mais on voit rapidement l’intérêt de ce système sur un graphe complexe composé de nombreux statuts ou de boucles dans les transitions !

Tips : utilisez les constantes PHP de Symfony pour déclarer vos états afin d’éviter de les écrire à plusieurs endroits.

 

En prime vous pouvez générer un graphe de votre workflow, parfait pour une présentation justement !

Conclusion

L’ambiance était au rendez-vous pour cette dixième édition du Symfony Live. Les présentations étaient axées sur les nouveautés de la version 4, avec des feedbacks assez intéressants. Dans l’ensemble ce fut un meeting enrichissant, vivement la onzième édition avec sans doute au moins les prémices de Symfony 5 dont la sortie est prévue pour novembre 2019.