Ma Symfony Live Paris 2025
Le Symfony Live Paris 2025 a été une première pour moi, agréable découverte après plusieurs années d’utilisation du framework. Des talks très intéressants par des orateurs passionnés, tout simplement génial.
Ça m'a également permis de faire le point sur l'évolution du framework, l'amélioration de l'expérience développeur (DX) et les nouvelles approches architecturales, de l'hébergement aux bases de données, en passant par l'authentification et les composants front-end.
Keynote de Fabien Potencier : Amélioration continue et DX
La conférence a débuté avec la keynote de Fabien Potencier. Après 20 ans, il a souligné les progrès importants dans l'expérience développeur (DX) de Symfony , avec un focus fort sur la documentation.
Symfony Mapper
Le nouveau Symfony Mapper Component (symfony/object-mapper) a été une annonce majeure. Il vise à simplifier l'application d'un objet source vers un objet cible , se distinguant du Serializer qui mappe un tableau vers un objet. L'idée conceptuelle est qu'un tableau n'est pas une structure de données stable, contrairement à un objet.
Le Mapper, fusionné en Symfony 7.3 , complète des outils existants et en concurrence avec des solutions comme Valinor ou AutoMapper (notamment celui de JoliCode). Il est recommandé de lire l'article OrmHate de Martin Fowler en parallèle de cette réflexion sur le mapping.
Franken PHP
Franken PHP est apparu comme un outil essentiel pour simplifier le déploiement des applications PHP. Construit sur Caddy (en Go) et remplaçant le classique combo Nginx + PHP-FPM , il propose de regrouper PHP et le serveur web en un seul process.
Franken PHP est compatible Docker et peut même être configuré en mode Worker en utilisant les goroutines et les channels. Une fonctionnalité très prometteuse est le combo Franken PHP et un watcher, visant le HMR en PHP, avec une potentielle fusion future dans les versions de PHP elles-mêmes.
Conseil pratique : L'ajout de bin/console cache:warmup au Dockerfile est recommandé. Cela permet de précharger le cache de l'application pré-compilée, évitant ainsi à l'utilisateur final le chargement initial post-rebuild.
API Platform 4
API Platform continue d'évoluer, notamment pour mieux gérer la complexité architecturale. Les notes ont mis en évidence la difficulté et l'illisibilité des attributs des ApiResource sur les entités Doctrine à long terme. Les groupes de sérialisation, initialement une solution, deviennent un fardeau.
La version 4 vise un découplage fort entre l'entité ORM et la ressource API. L'approche recommandée est de :
- Utiliser des Models orientés API et non l'entité Doctrine.
- S'appuyer sur les Providers et Processors d'API Platform.
- Adopter le Symfony Mapper Component pour gérer le mappage entre ces différentes couches.
Un sujet connexe a été l'utilisation d'API Platform sans Doctrine. La démonstration a exposé les dangers de la surexposition de données due à la facilité de Doctrine. Des techniques comme json_group_array ou json_object dans MySQL offrent de bonnes performances pour la récupération de données sans jointures , mais nécessitent l'utilisation de DTO et de solutions de mappage comme AutoMapper.
PassKeys (WebAuthn)
L'authentification a été abordée sous l'angle de PassKeys (WebAuthn). L'intégration des clés d'accès est simplifiée grâce à un package front-end globalement utilisable et une intégration rapide à Symfony via le webauthn-symfony-bundle. Cette solution permet la création de clés d'accès via le navigateur.
Gestion des droits et des permissions
Le contrôle d'accès a été détaillé avec le Symfony Voter , qui permet d'associer un système de "vote" à une demande de permission (via l'attribut IsGranted). La gestion des permissions peut être modulable (unanime, affirmative, consensus, priorité). Ces mécanismes soutiennent l'architecture d'applications monolithiques capables de gérer plusieurs marques blanches avec des noms de domaine personnalisés et une base utilisateur mutualisée.
Symfony UX / HTMX
Si la session sur Symfony UX (StimulusBundle, UxTurbo, TwigComponent, LiveComponent) était jugée difficile à suivre , une autre approche pour développer le front-end sans écrire de JavaScript complexe a retenu l'attention : SPA avec HTMX et Twig.
HTMX est une librairie très légère pour étendre les capacités front des développeurs back. En combinaison avec Turbo , elle permet de simuler une sensation de SPA grâce à hx-boost sur la navigation. Côté back, l'utilisation de renderBlock permet d'envoyer uniquement la portion de HTML modifiée. Bien que puissant, il est jugé plus adapté à des applications simples et peu dynamiques visuellement.
Mercure
Le protocole Mercure pour le feedback en temps réel a été mis en avant. Mercure est une surcouche au Server-Sent Events (SSE) , préférée aux WebSockets pour sa simplicité relative.
La consommation côté navigateur se fait via EventSource. L'intégration est particulièrement fluide avec Turbo, permettant une connexion SSE via turbo_stream_listen sans nécessiter de JavaScript.
Autres
- Messenger (Axe archi) : Une proposition a été faite pour un Messenger synchrone , visant à découper la logique métier en messages, le contrôleur ne faisant plus qu'un dispatch. L'idée est d'avoir des messages plus proches du métier.
- PDF : Présentation du Bundle Gotenberg, une API stateless (socle Docker) pour la gestion de fichiers PDF.
Hâte de ma prochaine !