Symfony Flex se présente comme une nouvelle structure pour nos projets Symfony et peut-être même LA nouvelle structure. Petit retour d'expérience sur les gains techniques de futures nouvelles normes.
Présentation de Flex
Flex est le futur de Symfony. Précédemment, l'initialisation d'un projet se faisait grâce à une base dite "standard" (symfony/standard) qui embarquait tous les composants Symfony. Depuis Symfony 3.3, vous pouvez désormais créer des projets Symfony à partir d'une base dite "Flex" (symfony/skeleton). Celle-ci se veut par défaut légère.
En fonction de vos utilisations, vous ajoutez les composants Symfony dont vous avez besoin.
symfony/translationpour les traductionssymfony/formpour générer des formulaires- et bien d'autres
Présenté comme une alternative à la version standard avec Symfony 3, ce système sera celui par défaut avec Symfony 4 bien que l'initialisation de la version standard sera toujours possible.
Contexte : pourquoi j'utilise Flex
Je travaille actuellement sur un projet Symfony 3 et je viens tout juste de finir la migration vers une structure Flex. La migration n'est pas "simple" car aucun outil n'a été développé. Il faut être rigoureux et suivre les indications données par Sensio. Au final, on réalise la migration assez rapidement quand on a compris le fonctionnement de Flex et son architecture.
En réalisant quelques recherches (voir toutes les sources en pied de page -- merci aux auteurs :-) ), j'ai trouvé un article du site symfony.fi comparant les performances entre les deux architectures disponibles.
La conclusion était une amélioration des performances de l'ordre de 20% entre Symfony 3 (Microkernel) et Flex bien que l'auteur ne veuille pas s'engager outre mesure sur des chiffres parfaitement exacts.
I wouldn't get too excited without more indepth analysis, but it looks like you get on average 20% improved throughput with the Microkernel and other improvements in Symfony Flex.
De mon côté voici l'état des changements/améliorations pour le passage d'un Symfony standard (non Microkernel) vers une architecture Flex.
Les dépendances
Les tailles du dossier vendor diminuent légèrement de mon côté... mais le gain reste faible. Certes, Flex embarque par défaut le minimum vital, mais la construction d'une application nous amène rapidement à importer quasiment l'intégralité des composants Symfony. De plus, certains composants ne sont pas stateless et l'ajout d'un composant entraînera probablement l'installation d'autres composants en arrière-plan. Le gain est donc relativement faible dans mon cas. Selon les projets le gain sera plus ou moins important.
Plus le projet est petit, plus Flex sera intéressant.
Benchmark
J'ai réalisé un petit benchmark des performances. Ces chiffres sont bien évidemment à prendre avec précaution, mon cas de test pouvant ne pas correspondre à l'intégralité des cas.
Le test a été particulièrement simple. Réaliser un siege sur l'environnement de production pendant 1 minute. Une fois, sans accès concurrent et une fois avec 10 concurrents simultanés. opcache et APCu ont été désactivés pour limiter l'effet de cache qui compense les latences I/O lors de l'accès aux fichiers.
Les chiffres rendus sur un graphique ne permettent pas de distinguer de différences comme vous pourrez le constater.
Utilisation de Flex : la conclusion
Symfony Flex apporte une architecture différente qui permet de toucher aussi bien les "gros" projets que les projets plus légers. Les gains de Flex seront d'ailleurs principalement visibles pour les petits projets ne nécessitant que quelques composants, comme faire le rendu d'une page, ou simplement gérer une API (dans ce dernier cas, il est inutile d'installer le composant de templating par exemple). Le système de dépendances reste facile à prendre en main et l'ajout de nouveaux composants se fera extrêmement rapidement. Toutefois, dans la pratique, les gains resteront plus faibles que sur des benchmarks comparant deux projets vides sans dépendance supplémentaire ajoutée.
En savoir plus sur Flex : les références à lire
-
JsonPath en PHP avec Symfony 7.3 : Pour des API Incassables, retour sur le talk d'Alexandre Daubois à l'AFUP DAY Lyon 2026Il y a 3 mois
À l'AFUP Lyon 2026, Alexandre Daubois (CTO chez Les-Tilleuls.coop, membre des core teams Symfony et FrankenPHP, et mainteneur PHP) a présenté un nouveau composant Symfony qu'il a lui-même proposé et mergé : JsonPath. Le titre du talk résume bien l'ambition : en finir avec le code fragile qui navigue dans du JSON à coups de tableaux PHP imbriqués.
-
Event Bus : Le secret d'une architecture Symfony réellement découpléeIl y a 8 mois
Imaginez : votre utilisateur clique sur "Commander". En coulisses, le domaine Stock doit décrémenter les quantités, le domaine Facturation doit générer une facture, et le domaine Notification doit envoyer un email de confirmation. Trois domaines, une seule action... et un spaghetti de dépendances en perspective. 🍝
Et si ces domaines pouvaient collaborer sans jamais se connaître ?
C'est exactement ce que permet l'Event Bus. Mais avant de foncer tête baissée, une question se pose : Symfony propose déjà l'EventDispatcher pour gérer les événements. Alors pourquoi introduire un nouveau concept ?
Spoiler : ce ne sont pas les mêmes outils, et les confondre peut vous coûter cher.
Dans cet article, nous allons démystifier leurs différences et découvrir comment l'Event Bus de Symfony Messenger vous permet de construire une architecture réellement découplée.
Ce que vous allez apprendre :
- Les différences fondamentales entre
EventDispatcheretEvent Bus - Quand utiliser l'un plutôt que l'autre
- Comment configurer un
Event BusavecSymfony Messenger - Créer une architecture événementielle découplée
- Les différences fondamentales entre
-
CQRS avec Symfony Messenger : Domptez la complexité de vos applicationsIl y a 8 mois
Vous êtes-vous déjà retrouvé face à un controller Symfony surchargé qui gère à la fois la validation, la logique métier, la persistence et les réponses HTTP ? Si oui, le CQRS est fait pour vous !
Le CQRS (Command Query Responsibility Segregation) est un pattern architectural qui sépare clairement les opérations d'écriture (Commands) et de lecture (Queries). Combiné avec Symfony Messenger, il vous permet de :
- Organiser votre code de manière claire et maintenable
- Séparer les responsabilités pour respecter les principes SOLID
- Valider vos données avant même qu'elles n'atteignent votre logique métier
- Gérer les transactions de base de données de manière élégante
- Préparer votre application pour l'asynchrone sans effort
Dans cet article, nous allons explorer les Commands (écriture) et les Queries (lecture) à travers un exemple concret de gestion de bibliothèque.
-
Gagner en performance et confort de développement : aperçu des nouveautés dans Symfony 6.3SymfonyIl y a 3 ans
Suite à la migration d'un de nos projets en version Symfony 6.3 nous avons voulu partager les nouveautés qui ont le plus marqué notre attention.
-
Le BDD (Behavior Driven Development) avec Behat et SymfonyIl y a 3 ans
Le sujet des tests fonctionnels est une (longue) histoire chez Wanadev. Notre projet Kazaplan grossissant de plus en plus, nous sommes obligés d'adopter une politique de tests plus en plus stricte au fur et à mesure de l'avancement du projet.
-
Créer facilement une API REST avec Symfony & API PlatformIl y a 6 ans
Au menu aujourd'hui, je vous ai concocté un petit article gourmand croquant, sur un framework devenu très populaire au sein de la communauté Symfony dans la mise en place d'API, j’ai nommé le fameux API Platform.