Le blog

SymfonyLive Paris 2024 : notre retour sur les conférences

Publié le 11 avril 2024

Il y a quelques jours, nous avons participé à la quinzième édition du SymfonyLive Paris, l’événement monotrack francophone axé sur le framework Symfony et son écosystème. Keynotes, contributions ou cas d’usages concrets étaient au programme de ces deux jours de conférences durant lesquels nous avons pu faire la connaissance des participants rencontrés sur notre stand Gold. Découvrons ensemble le déroulé de cet événement 100% Symfony ainsi que les talks qui ont retenu notre attention.

Photo de la devanture de la cité internationale universitaire de Paris" class="wp-image-8796" style="aspect-ratio:3/2;object-fit:cover#

De la montée en compétences 

La veille des conférences, notre coopérateur Kévin Dunglas a eu l’opportunité d’animer un workshop d’initiation à l’utilisation d’API Platform. Si vous n’avez pas pu y participer, n’hésitez pas à consulter notre catalogue de formations qui propose aussi bien une initiation à API Platform que des sessions plus approfondies, par exemple axées sur le Domain-Driven Design couplé au framework.

#

Les récentes contributions de l’écosystème

Fabien Potencier a donné le coup d’envoi du SymfonyLive par sa keynote d'ouverture. Il a présenté l'utilisation de Git dans le quotidien du framework, en revenant plus précisément sur le découpage automatique effectué depuis le dépôt principal symfony/symfony vers les dépôts de chaque composant. En effet, pour faciliter la contribution, le dialogue et la gestion des versions, un seul dépôt centralise tout le code du framework. Afin de proposer chacun des composants de manière indépendante sur Packagist et de laisser le choix aux devs, le dépôt principal doit être divisé. La complexité étant de garder un même historique de commits sur chacun des dépôts pour garantir une meilleure lisibilité et facilité la maintenance. Après avoir exploré les possibilités de Git avec la commande git subtree split, le créateur de Symfony a présenté son outil splitsh/lite permettant d’obtenir le résultat attendu en un temps d'exécution drastiquement meilleur. C’est également l’occasion de revenir sur les commandes internes de Git, regroupées sous le terme “plomberie” (en opposition aux commandes “porcelaine”) et plus largement sur les notions d’arbre, de blob et de métadonnées d’un commit.

Photo de Fabien Potencier sur la scène du SymfonyLive" class="wp-image-8799" style="aspect-ratio:3/2;object-fit:cover

Mathias Arlaud et Baptiste Leduc ont présenté leur travaux liés au composant Serializer. Après un rappel des concepts de la sérialisation dans Symfony, les deux conférenciers ont abordé les limites du composant actuel. Tout d’abord,  son architecture repose sur trois classes qui s’étendent dont deux sont abstraites, ce qui rend difficile la personnalisation. Également mentionnée, l’utilisation de l’API Reflection, qui malgré les améliorations des versions récentes de PHP, reste un problème pour la performance et la limitation du typage (limitation inhérente à la fois au format JSON et à l’outillage présent dans Symfony). Concernant ce dernier point, Mathias a présenté un nouveau composant TypeInfo, ajouté dans la dernière version du framework qui vient remplacer et surtout compléter PropertyInfo, en ajoutant les fonctionnalités d’union et d’intersection de type, les énumérations ou encore la généricité, et surtout couvrir les types de tous les paramètres et pas seulement ceux du constructeur. La présentation s’est poursuivie avec d’autres propositions de composants, pas encore ajoutés à Symfony mais disponibles sur GitHub. Premièrement, le composant JsonEncoder ayant pour vocation de remplacer la fonction json_encode avec une réduction de la consommation de mémoire notamment en utilisant des streams. Baptiste poursuit avec la présentation du composant AutoMapper, migré de janephp/automapper vers jolicode/automapper depuis peu et qui propose dans sa nouvelle version d’utiliser les attributs PHP. 

La conférence s’est conclue avec la présentation d’un dépôt GitHub combinant tous les composants précédents afin de réaliser des tests de performance. Résultats : la réduction du temps nécessaire pour réaliser les opérations de serialization et deserialization est de l’ordre d’un facteur 10. Les avancées sur l’introduction du composant ObjectMapper dans Symfony (initiée par notre coopérateur Antoine Bluchet) peuvent être suivies sur GitHub.

#

L’architecture des applications 

Notre coopérateur Kévin Dunglas a présenté un sujet portant sur l’architecture d’application, en détaillant deux paradigmes différents utilisés pour la conception d’applications web : l’approche de la Radical Simplicity et celle plus populaire des Single Page Applications (SPA).

Photo de Kévin Dunglas sur la scène du SymfonyLive Paris" class="wp-image-8800" style="aspect-ratio:3/2;object-fit:cover

La première prône la simplicité en utilisant le moins de services possibles : un monolithe avec FrankenPHP et Symfony pour la partie applicative et un service unique pour la persistence des données. Le front est réalisé grâce à Symfony et Twig qui permet d’avoir une expérience utilisateur enrichie grâce à un ensemble de composants ajoutés ces dernières années :  UX et AssetMapper. L’utilisation de Turbo (Drive et Frames) permet d’atteindre une expérience similaire à une SPA tout en conservant le monolithe. Pour plus d’interactivité, l’ajout de Mercure combiné aux streams de Turbo permet la mise à jour en temps réel.

Si les besoins dépassent ceux de l’approche simple, il convient alors d’utiliser une solution plus complète, avec plus de services. La distribution d’API Platform répond à ce besoin en proposant un back avec Symfony et API Platform, un client SPA généré au choix parmi plusieurs frameworks JavaScript (React & Next.js, Vue.js & Nuxt ou React Native & Expo) et un client pour l’administration basé sur React Admin. La mise en place est facilitée par la découverte automatique des ressources d’API grace aux normes de documentation (Hydra ou OpenAPI) et à la mise à disposition de fichiers Docker et de templates Helm pour Kubernetes. 

Jérémy Romey a abordé dans sa conférence l’approche de conception orientée métier à travers deux concepts l’Event Storming et le pattern CQRS. Après avoir passé en revue les définitions théoriques de base, il continue avec un exemple servant de fil rouge. Il commence avec l’approche la plus simple et habituelle, celle consistant à utiliser des objets, les modifier et gérer leur cycle de vie grâce aux opérations CRUD. Il poursuit par la gestion événementielle, en attirant l’attention sur ce qui amène la mutation de l’objet plutôt que l’état qui en résulte.

Il reprend les définitions théoriques avec les notions introduites par l’Event Storming, passant en revue les concepts Event, Command, Read Model, Policy, Aggregate, Entity et Projection. Il continue avec la mise en pratique, en nous indiquant que le framework Symfony dispose de tous les composants permettant la mise en œuvre de ces concepts. Nous voyons plus précisément l’implémentation de l’agrégat et ses relations avec les événements, leur enregistrement de l’Event Store grâce aux Repositories et à Doctrine. Viennent ensuite les implémentations des bus (Event, Projection, Policy, Command) grâce aux composants EventDispatcher et Messenger. Les composants Webhook et Scheduler permettent également de déclencher des événements par le système (en complément des Commands qui, elles, sont déclenchées par l’utilisateur). L’implémentation des Read Models et des Projections est réalisée avec des objets, l’injection de dépendances est utilisée pour lier toutes les classes entre elles. Il termine sa conférence en dévoilant le code implémentant les concepts présentés précédemment, mais appliqués à des règles et des événements métier concrets.

#

Des bonnes pratiques

Grégoire Pineau, membre de la core team de Symfony, s’est proposé d’explorer sur scène les logs et l’étendue des outils à disposition des développeurs. Après les définitions théoriques sur l’observabilité et plus précisément sur les logs, il a abordé les outils à disposition dans Symfony, que ce soit à travers les interfaces des PSR ou de leurs déclinaisons concrètes grâce à Monolog. Il a continué avec des concepts propres à ce bundle. Tout d’abord les Processors qui permettent de modifier les enregistrements de log après génération, principalement pour agir sur le contexte. Certains sont fournis avec Symfony ou Monolog et quelques exemples d’implémentation personnalisée sont données, nous retenons l’UuidProcessor utile pour mettre en place un identifiant de corrélation. 

Photo de Grégoire Pineau sur la scène du SymfonyLive Paris" class="wp-image-8801" style="aspect-ratio:3/2;object-fit:cover

Il nous présente ensuite les channels, dont le rôle principal est d’organiser les messages de logs en les diffusant sur des canaux. Puis les Handlers qui vont permettre de définir des filtres et des destinations pour les messages. Enfin les Formatters qui définissent le format dans lequel l’entrée de log sera convertie avant son envoi. Le développeur de JoliCode termine en présentant des configurations plus avancées et un panorama des solutions de stockage.

Cette conférence était pleine de conseils avisés, de bonnes pratiques et aussi des solutions concrètes à des problèmes que tout·e dev est amené·e à rencontrer. Nous retenons entre autres : 

  • Avoir des messages descriptifs, uniques et simples.
  • Utiliser le contexte pour passer des variables (deuxième paramètre des méthodes de LoggerInterface) et des Processors pour appliquer un traitement.
  • Avoir des logs partout et même quand cela se passe bien.
  • Les transports non-bloquants doivent être privilégiés afin d’éviter un point de défaillance unique si le service sous-jacent ne répond pas.
  • Privilégier un format JSON qui sera mieux interprété par les outils d’extraction et d’exploitation de logs.

Nicolas Grekas est revenu sur les manières de contribuer à Symfony, de la récupération du code source jusqu'à la création d’une Pull Request sur GitHub, sans oublier le passage par les tests. Il a enchaîné ensuite avec la présentation des nouveautés de la version 7.1 de Symfony, après un bref rappel sur le cycle de vie des versions. Côté composants, le principal contributeur de Symfony nous présente TypeInfo,  le remplaçant de PropertyInfo et Emoji, extrait depuis le composant Intl. Quelques bridges pour Notifier et Mailer ont également été ajoutés. Il poursuit avec l’ajout d’attributs pour l’injection de dépendances, un nouveau client HTTP gérant le throttling, des nouveautés dans UX et sur UUID (v6/v7) ainsi que des améliorations au niveau de l’expérience développeur (DX).

Les nouveaux composants qui pourraient rejoindre la version 7.2 sont également présentés : JsonEncoder, FeatureFlags, AccessToken pour la communication de serveur à serveur ou encore ObjectMapper proposé par notre coopérateur Antoine Bluchet. 

Jérôme Tamarelle, membre de la core team Symfony et développeur chez MongoDB, a présenté de manière détaillée les attributs introduits dans la version 8 de PHP. Après un rapide retour sur les différentes syntaxes proposées et expérimentées, il a passé en revue les attributs natifs. Nous retenons notamment SensitiveParameter qui permet de cacher la valeur des propriétés dans les traces de log, le plus récent Override qui permet d'identifier les méthodes des classes parentes ou interfaces ou le plus largement utilisé Attribute permettant de définir ses propres attributs.

La conférence a continué ensuite avec les attributs créés par JetBrains pour remplacer la PHPDoc (ArrayShape, par exemple), ceux de Doctrine qui viennent remplacer les annotations déjà bien connues par les utilisateurs de l'ORM et enfin ceux de Symfony, toujours plus nombreux avec les versions successives. On retiendra notamment toutes les configurations de service rendues possibles directement depuis la classe PHP au détriment du fichier services.yaml qui étaient la préconisation jusque-là, c'est aussi l'occasion de rappeler la fin de vie du bundle SensioFrameworkExtraBundle. En dehors des attributs d'autoconfiguration préfixés par As (i.e. AsController, AsDecorator ou AsEventListener), nous retenons également tous les attributs liés à  l'autowiring commençant par Autowire. D'autres attributs existent pour l'injection de dépendances, la validation, plus récemment le composant Scheduler ou UX, sans oublier les plus classiques pour la sérialisation. Nous en profitons pour ajouter qu'une liste complète est disponible sur https://symfony.com/doc/current/reference/attributes.html et que ceux d'API Platform sont disponibles dans la section Metadata sur https://api-platform.com/docs/references/.

#

Conclusion 

Comme chaque année, nous avons passé un bon moment au SymfonyLive Paris, qui nous accueille dans un cadre fabuleux et une architecture atypique. Le niveau des sujets était varié : des talks introductifs comme d’autres plus pointus ont rythmé ces deux jours de conférences. C’est toujours un plaisir pour nous de rencontrer la communauté Symfony sur place : notre stand ne s’est jamais désempli, nous avons eu de nombreux échanges intéressants et même l’opportunité de participer à l’aftermovie de l’événement !

Le blog

Pour aller plus loin