Le SymfonyLive Paris 2025 comme si vous y étiez - Jour 1
Publié le 01 avril 2025
La semaine dernière s'est tenu le SymfonyLive Paris, un événement incontournable de la communauté PHP francophone, organisé à la Cité Internationale Universitaire. Il s'agissait de notre onzième participation depuis la fondation de notre entreprise, et cette année, nous avons eu la chance de monter sur scène à deux reprises. Revenons sur chaque conférence de cet événement qui a rassemblé plusieurs centaines de développeurs et développeuses.
#Symfony in 2025: Scaling to 0 - Fabien Potencier
À l’occasion des 20 ans de Symfony, son créateur Fabien Potencier est revenu sur des éléments clés de son histoire avec quatre axes de progression : code, documentation, DX et communauté.
Fabien a commencé par rappeler que le microframework Silex a été abandonné suite à l’arrivée de Symfony 4 et de Flex. Selon lui, l'amélioration de la DX passe par plusieurs axes : une meilleure documentation, une communauté active et la modularité des composants. Une bonne DX pouvant même réduire le besoin de documentation.
Fabien a ensuite présenté quelques concepts intéressants, rendus possibles par Flex, rendant Silex caduc :
- Symfony Hello : un "Hello World" minimaliste avec un
Kernelseul. En Symfony 7.3,execute()pourra être remplacé par__invoke(), avec configuration en paramètres. - Symfony Solo : une version sans Flex où la config des bundles est manuelle.
- Symfony Team : le framework Symfony classique.
Une nouveauté à retenir de cette keynote : le profiler est désormais utilisable sur les commandes via l’option --profile.
Le Composant Symfony Mapper - Antoine Bluchet
Notre coopérateur Antoine Bluchet présente un nouveau composant: “Object Mapper”.
Il commence par un rappel historique des différents travaux menés par Jolicode sur le mapping d’objets. En effet, en vue d’améliorer les performances, ils ont œuvré à trouver une amélioration pour les Normalizers de Symfony qui consiste à pré-charger du code PHP qui réplique la normalisation afin qu’à l'exécution les calculs ne soient plus à faire. On observe d’ailleurs de très bonnes performances et ils ont externalisé leur code dans la librairie AutoMapper.
// src/Dto/Source.php
namespace App\Dto;
use App\Entity\Book;
use Symfony\Component\ObjectMapper\Attributes\Map;
#[Map(target: Book::class)]
class BookRepresentation {}L’idée est d’adopter une approche simple et pratique pour les cas les plus courants, et de proposer une extensibilité à l’aide d’une Factory lorsque l’on veut faire des cas plus avancés comme configurer le Mapping dans un service à la MapStruct.
L’attribut Map peut aussi s’apposer sur des propriétés il comporte deux options :
ifpermet de conditionner le mappingtransformpermet de transformer la valeur (via un service ou une Closure)
Nous voyons ensuite comment ce nouvel outil simplifie la gestion des ressources dans API Platform, en automatisant la synchronisation entre entités et DTO. L’implémentation est disponible sur Github. Ce nouveau composant, encore expérimental, arrivera avec Symfony 7.3 et sera intégré à API Platform 4.2. Le composant est mergé dans Symfony et nous travaillons actuellement sur la documentation.
Postgres pour vos besoins NoSQL - David Buchmann
David Buchman nous présente des usages poussés du SQL à travers l'utilisation du type JSON dans PostgreSQL avec Doctrine, nous en retenons les éléments-clés suivants :
- PostgreSQL permet de stocker des objets JSON directement dans ses tables.
- Il existe plusieurs types pour gérer le JSON, mais JSONB est le plus recommandé, car il est optimisé pour la recherche et l'indexation et évite les répétitions inutiles de clés et améliore les performances en lecture.
- L'index GIN (Generalized Inverted Index) est particulièrement adapté pour la recherche dans les JSONB. Il est cependant très lent en écriture et gourmand en stockage
- Doctrine prend en charge partiellement le format JSON via le type
Types::JSON, qui s'active automatiquement sur une propriété de typearray.
Côté standardisation, chaque SGBD a sa propre approche : MySQL supporte JSON, mais ce n’est pas le cas de MariaDB. Enfin, les problèmes de performance ne se posent qu’au-delà de 10 000 lignes, donc inutile d’optimiser prématurément si ce seuil ne sera jamais atteint.
Passkeys pour une authentification fluide et sécurisée - Rémi Janot
Rémi Janot est revenu sur l’évolution de l’authentification, des mots de passe (apparus dans les années 1960) à l’authentification à deux facteurs (2FA), popularisée en 2011. Aujourd’hui, un mot de passe sécurisé doit contenir au moins 14 caractères alphanumériques, mais reste vulnérable au phishing.
WebAuthn apporte une solution plus robuste via une API JavaScript et un authentificateur matériel ou logiciel. Tous les navigateurs modernes le supportent (avec quelques frictions sur Firefox/TouchID). En PHP, WebAuthn repose sur un mécanisme de clés privées/publiques stockées côté serveur. À l’authentification, le serveur génère un challenge, signé par le dispositif de l’utilisateur et vérifié côté serveur.
L’intégration avec Symfony se fait via le bundle web-authn/webauthn-symfony-bundle. Quelques configurations sont nécessaires dans le fichier security.yml.
À noter :
- WebAuthn améliore la sécurité, mais nécessite du matériel compatible.
- Un compteur permet d’éviter les attaques par rejeu.
- Les passkeys ont des limites (ex : une Yubikey stocke max 25 clés).
- WebAuthn ne fonctionne pas en navigation privée (du moins sur Chrome).
Une démo est disponible sur GitHub.
Symfony UX : Points forts de 2024 et perspectives d'avenir - Simon André
Simon André a retracé les cinq dernières années de l’initiative Symfony UX, avec une rétrospective marquante sur 2024 : création d’une équipe UX, adoption croissante par des acteurs majeurs (Symfony, EasyAdminBundle, Sylius, SensioLabs, ministère de l’Intérieur) et une explosion des téléchargements (15 millions en 2024, contre 4 millions en 2023).
Parmi les composants clés, nous notons :
- StimulusBundle (100k/semaine) et Turbo (50k/semaine) inclus par défaut dans Symfony UX.
- Twig Components (95k/semaine) et Live Components (40k/semaine), ce dernier ayant la doc la plus longue du site Symfony.
- UX Icons, lancé en sept. 2024, déjà adopté par PrestaShop.
- Lazy Image (1,4k/semaine) sera déprécié, les navigateurs gérant désormais cette fonctionnalité nativement.
- UX Map, lancé en janvier 2025, facilite l’intégration de cartes Leaflet/Google Maps.
Pour son futur, Symfony UX prévoit plusieurs évolutions :
- UX Website : l'amélioration du site actuel pour y rapatrier la documentation UX se trouvant sur le site Symfony.
- UX Toolkit : un outil permettant aux utilisateurs, depuis une commande Symfony, de télécharger des composants Twig prêts et customisables.
Rôles et permissions : développez une marque blanche avec du Feature Flipping - Florian Bogey
Florian Bogey a présenté les stratégies de gestion des permissions et du déploiement progressif utilisées chez GL events, un fournisseur de logiciels pour l’événementiel. Il a expliqué que les rôles sont attribués de manière statique pour définir les actions globales qu’un utilisateur peut effectuer, tandis que les permissions sont vérifiées dynamiquement via des Voters. Ces derniers permettent un contrôle plus précis des actions autorisées, et l’utilisation de IsGranted(action_name: string, obj: object) permet de gérer ces accès.
Il a également abordé le concept de feature flipping, une technique permettant de déployer du code sans l’activer immédiatement pour tous les utilisateurs, assurant ainsi un déploiement progressif et sécurisé. Plusieurs solutions existent, notamment des bundles Symfony, ainsi que des outils comme GitLab et JIRA, mais GL events utilise aussi une solution maison qui offre une plus grande flexibilité en activant des fonctionnalités en fonction de l’utilisateur et du contexte.
API Platform sans Doctrine - Jérôme Tamarelle
Jérôme Tamarelle a présenté des techniques d’optimisation des requêtes dans API Platform, illustrées à travers une recette de lasagnes. L’un des principaux défis réside dans la multiplication des requêtes SQL :
- Une simple requête pour récupérer une recette génère 300 requêtes (lazy loading…).
- Les opérations d’insertion et de mise à jour sont aussi inefficaces (30 requêtes pour une insertion, 10 pour mettre à jour l’ordre des étapes).
Pour optimiser ce fonctionnement en SQL, une approche consiste à regrouper les jointures sous forme d’objets JSON (json_group_array() et json_object()). Cela permet de réduire l’ensemble des requêtes à une seule, et d’hydrater l’entité via un Mapper (cf. talk d’Antoine Bluchet).
Cependant, MongoDB se révèle être une alternative plus adaptée :
- API Platform peut fonctionner sans Doctrine.
- Les opérations sont simplifiées avec moins de 100 lignes de code :
Selon lui, utiliser MongoDB avec API Platform permet une exécution des requêtes bien plus performante et fluide.
Développer plus vite grâce à FrankenPHP - Kévin Dunglas
Notre coopérateur Kévin Dunglas a conclu cette première journée de conférences en rappelant que le secret de la performance de Symfony réside dans sa facilité d’utilisation et sa capacité à se reposer sur des conventions comme l’auto-découverte des services, l’autowiring, et l’autoconfiguration. Le framework utilise des formats de fichier et des fonctionnalités du langage, comme les attributs, YAML, et Twig, ce qui le rend très user-friendly. Cependant, ces facilités génèrent un coût en termes de parsing, compilation, I/O, et réflexion d’API, ce qui peut entraîner des lenteurs.
Pour pallier ces problèmes, Symfony utilise des composants dédiés comme Config, qui parse la configuration et la convertit en fichiers PHP, DependencyInjection, qui transforme la configuration en un graphe de services, et Routing, qui utilise Config. Twig convertit les templates en fichiers PHP, tandis que Cache conserve les résultats des calculs pour éviter de les refaire à chaque fois. Résultat : Symfony est lent au premier chargement, mais une fois le cache généré, les performances sont nettement améliorées.
En production, le cache est idéalement généré une seule fois lors du build via la commande cache:warmup, ce qui permet d'éviter des recalculs inutiles. En développement, le cache est fréquemment rafraîchi en fonction des modifications du code, ce qui peut rendre certaines opérations lentes.
Avec FrankenPHP, qui utilise un mode worker lancé avec le serveur web, il n'était pas possible de l'utiliser en environnement de développement avant la version 1.4. Mais désormais, grâce à un mode "watcher", FrankenPHP peut surveiller les changements de fichiers à l'aide de e-dant/watcher. Cette solution multiplateforme permet à FrankenPHP de redémarrer automatiquement dès qu'un fichier est modifié, entraînant le rafraîchissement des caches par Symfony.
Rendez-vous demain pour la suite de notre compte-rendu !
