change de nom...
La conférence a commencé avec une Keynote de Fabien Potencier.
Mais c’est lors du talk suivant que Antoine Bluchet nous a présenté un nouveau composant de Symfony : le composant Mapper.
Le but de ce composant est simple : proposer une interface afin de convertir un objet vers un autre objet. Le principal avantage est de découpler les objets métiers de leur représentation plus proche de l’infrastructure (entité Doctrine, DTO provenant d’une API…).
L’historique de ce composant est assez riche. Plusieurs paquets PHP ont déjà été conçus dans le but de proposer une interface unique pour des besoins de mapping :
Le composant s’inspire également de ce qui est fait dans d’autres langages et frameworks, tels que AutoMapper pour .NET, ou MapStruct pour Java
Le composant Mapper a été mergé, et sera disponible dans Symfony 7.3.
Chez Codéin, nous avons hâte de l’utiliser pour nos besoins de séparation entre notre modèle métier et les différentes couches d’infrastructure. Ces implémentations peuvent concerner les formulaires Symfony, les entités Doctrine, des réponses d’API tierces avec HttpClient, ou encore pour la construction de nos propres APIs avec API Platform, qui a également été un des sujets centraux lors de la conférence.
Beaucoup de talks discutaient de sujets autour d’API Platform. Nous allons parler ici du talk “Développer avec API Platform 4, ça change quoi ?” par Mathias Arlaud.
Les dernières évolutions d’API Platform, et notamment sa version 4 marquent un tournant : il est désormais possible de découpler totalement les ApiResource des entités Doctrine, sans perdre les fonctionnalités clés telles que la pagination ou les filtres intégrés.
On a évidemment un intérêt à séparer les ApiResource des entités :
Une intégration avec le nouveau composant Symfony Mapper est aussi attendue, ce qui faciliterait davantage le découplage et la clarté de l’architecture.
Plusieurs talks ont été dédiés à Symfony Messenger lors de Symfony Live Paris 2025.
Pour rappel : Messenger est un composant qui permet de gérer des messages pour faire des traitements qui sont, dans la plupart des cas, asynchrones. Le composant peut également communiquer avec un agent de messages, comme RabbitMQ ou Amazon SQS. Lors de la conférence, nous avons eu deux principaux retours d’expérience sur l’utilisation de ce composant.
Le premier est l’utilisation de Messenger, Mercure et Turbo pour offrir une expérience utilisateur plus fluide dans le contexte d’un long traitement (un import de fichier par exemple). Pour Messenger, c’est un cas d’école : un traitement aussi long doit pouvoir se faire en asynchrone, afin de ne pas bloquer de processus côté serveur web et risquer un timeout. Le passage du traitement en asynchrone a néanmoins un inconvénient : si le client n’a pas de retour instantané sur l’opération voulu par l’utilisateur, il est plus difficile de prévoir une interface intuitive pour ce dernier.
C’est donc là qu'intervient le duo Mercure et Turbo : l’un va diffuser en temps réel l’avancement du traitement, et l’autre va s’occuper de mettre à jour l’affichage de la page web avec cette information. Un cas d’usage qui montre que nous pouvons créer des expériences utilisateurs très satisfaisantes en utilisant exclusivement des composants Symfony.
Le deuxième talk sur Messenger aborde une autre approche du composant : celle de son usage dans un contexte synchrone. Car si le composant est d’abord pensé pour gérer des messages de manière asynchrone via différents “transports” comme RabbitMQ ou simplement Doctrine, il peut également traiter les messages de manière synchrone et rendre ainsi la main au code appelant à la fin du traitement. Il s’agit d’un usage qui peut faire penser à ce que fait déjà le composant EventDispatcher, mais le raisonnement est différent.
Là où un système d’écouteurs classique peut permettre d’étendre un système, un “bus de message” s’attend à ce que quelque chose soit fait, que le message soit pris en compte. En outre, le principal avantage de ce système est que le traitement lui-même est modélisé via un message, et on peut donc le manipuler avec des Middlewares, ou l’annoter avec des Stamps.
Cette utilisation de Messenger est très intéressante en termes de découplage, et peut même s’inscrire facilement dans un pattern CQRS par exemple.
En ce qui concerne Messenger, il ne faut pas oublier que toute cette magie a un prix côté infrastructure. Il faut penser au choix du transport, au traitement des messages, à la mise en place du Hub Mercure, de la solution côté front etc… Malgré tous ces prérequis, Messenger (et les agents de messages en règle générale) restent quand même des outils très puissants, parfois trop peu souvent utilisés, pour améliorer la disponibilité de nos applications ; et il existe des solutions pour offrir en complément une expérience utilisateur de qualité.
La volonté d’intégrer les considérations front-end moderne se fait sentir de plus en plus dans l'écosystème Symfony, au même titre que le secteur du web dans sa globalité.
On pourra sans mal se souvenir de l’époque pas si lointaine où un moteur de template tel que Twig et VanillaJS / JQuery étaient les deux seuls types de technologies à connaître.
Tout en se séparant du Back de plus en plus, le Front s’est professionnalisé, créant ainsi des frameworks tels qu’Angular, React, et Vue.js.
Symfony UX, une initiative au sein de l’écosystème Symfony, propose des bridges pour les applicatifs React et Vue.js notamment.
Symfony UX propose aussi des technologies alternatives avec pour objectif d’améliorer la DX (developer experience) au sein de Symfony. Par exemple, Symfony Live Components permet de développer une UI interactive en PHP & Twig, sans avoir besoin de faire du JS.
Un autre talk proposait l’utilisation d’HTMX, qui est aussi une manière de se passer de l’utilisation de Javascript, pour un grand nombre de besoins communs (y compris les requêtes AJAX).
Les sujets que nous avons traités précédemment sont des sujets récurrents et communs à plusieurs talks.
Aussi, plusieurs autres sujets de talks ont attiré notre attention :
Symfony Live 2025 confirme que l’écosystème Symfony continue de progresser dans une direction centrée sur l’expérience développeur (DX), tout en intégrant davantage les problématiques front-end grâce à l’initiative Symfony UX.
Nous utilisons déjà Messenger et API Platform dans nos projets, et l’accent mis sur ces technologies pendant l’événement valide les choix que nous avons faits.
Pour en savoir plus et (re)vivre les échanges passionnants avec Romain et Nico, visionnez le live ici : https://www.youtube.com/watch?v=fPEN-vjgZwY
À la recherche d'une nouvelle opportunité ?
Voir toutes les offres
À la recherche d'une nouvelle opportunité ?
Voir toutes les offres
Découvrez quelques uns de nos projets Symfony
Voir les projets
