Cet article a été rédigé avec Didier et Lucas, Référent technique Symfony et Développeur Symfony à l’Agence Dn’D
Le 9 avril se déroulait l’édition française de SymfonyLive Online 2021. Crise sanitaire oblige, l’événement s’est déroulé à 100 % à distance. Durant cette journée de conférences en ligne, d’importantes informations sur l’univers Symfony ont été dévoilées.
Les équipes techniques de Dn’D étaient présentes à l’événement et vous proposent de revenir sur les conférences qui ont retenu leur attention !
« Boring is the new hype »
Le choix des bonnes technologies pour mener à bien son projet
Pour mener à bien un projet, l’adaptation au contexte est toujours la clé pour faire le bon choix. Selon Fabien Potencier (fondateur de Symfony et Project Lead), le contexte se définit sous plusieurs aspects (l’application, l’équipe, la cible, le budget..) et doit être minutieusement étudié afin de ne pas emprunter la mauvaise direction pour le bon déroulement d’un projet. En effet, une mauvaise analyse du contexte entraîne la prise de décisions inadéquates, ce qui induit des pertes d’argent plus ou moins importantes.
Il n’est pas forcément nécessaire de se calquer sur les méthodologies et/ou sur les choix de grosses sociétés, car cela n’est pas toujours représentatif de notre contexte à l’instant T. D’après Fabien : « Sans contexte, il n’y a pas de bonne pratique ».
L’une des clés pour mener à bien un projet réside dans le fait de choisir d’utiliser des technologies éprouvées, reconnues au sein de la communauté et bien documentées. Il ne faut pas se précipiter sur des technologies récentes, qui ne sont pas suffisamment matures (sans oublier que le fait d’ajouter une nouvelle technologie représente un coût !). Aujourd’hui, Symfony est reconnue comme étant une technologie éprouvée et stable depuis de longues années (Symfony 2 : la logique du core a peu évolué depuis cette version).
La stack technique recommandée par Fabien est la suivante : PHP, PostgreSQL, très peu de JavaScript et SaaS (il préconise d’utiliser certains services externes pour limiter la dette technique de l’applicatif). Le choix de PostgreSQL se justifie par le fait que, dans un usage avancé, il permet d’obtenir plus de latitude que MySQL et d’assurer la gestion de l’asynchrone via un message queue (Symfony Notifier / Listen Notify PSQL). En clair, la couverture fonctionnelle et technique de PostgreSQL permet d’éviter l’ajout de services tiers tels que RabbitMQ ou encore Redis, tout en allégeant la stack technique.
Fabien précise qu’il existe peu de dépendances vers des packages extérieurs à Symfony. Par la suite, il introduit le label « Trusted » Bundle, validé par la Core Team sur les packages non-officiels. Pour Fabien, l’usage de Symfony UX est judicieux, dans le sens où Yarn et Webpack sont devenues des technologies éprouvées : en les utilisant avec Symfony Flex, cela peut donner des résultats très intéressants.
Focus sur l’infrastructure
Il est intéressant de privilégier l’utilisation du SaaS afin de rester concentré sur l’expertise du développement. Symfony propose du SaaS et adapte la solution afin de couvrir des besoins primaires tels que la gestion des traductions. Pour terminer ce talk, Fabien évoque le fait qu’il est judicieux de mettre à jour Symfony tous les 6 mois, puis il dévoile la stack idéale pour aborder l’aspect « Infrastructure » dans les meilleures conditions : SaaS, PostgreSQL, CDN et 1VM.
« Une sérialisation adaptée avec API Platform et Symfony »
Dans ce talk, Mathias Arlaud (Développeur PHP chez SensioLabs) explique la notion de « sérialisation » : cela consiste à représenter une structure de données dans un format, afin de l’envoyer / la faire persister, puis de la reconstruire. Il est possible d’effectuer de la sérialisation via API Platform, une fois que les ressources sont déclarées. Il s’agit d’une sérialisation configurable et nominale via l’utilisation de l’annotation “#[Ignore]”. Finalement, il s’agit de mettre à jour la documentation de chaque property pour configurer la visibilité dans l’objet retourné. La sérialisation / désérialisation intègre le context qui permet d’obtenir la latitude ci-dessous sur la configuration (afin de savoir si la valeur doit être affichée, si elle fait partie d’un groupe, etc.) :
API Platform se base sur la philosophie de Symfony pour faciliter la sérialisation / désérialisation de la donnée. Si l’on souhaite appliquer une logique supplémentaire afin d’altérer le comportement d’API Platform, on décore le service, on récupère la donnée et on altère en fonction de la logique cible. On peut aussi avoir un système de vérification sur les droits de l’utilisateur, si celui-ci a le niveau de droit nécessaire pour voir la valeur.
Pour clôturer ce talk, Mathias répond à une question intéressante d’un internaute : comment s’imprégner de tout ce mapping des ressources via API Platform sur un projet avec beaucoup de ressources, de jointures et de properties ? Mathias explique qu’avant de mettre en place les annotations, il est nécessaire de définir une convention au projet, afin que n’importe quel utilisateur puisse pleinement le comprendre sans faire trop de rétro-engineering.
« Comment nous avons tiré parti de symfony/http-client pour construire un nouveau SDK AWS »
AWS fournit un SDK PHP performant, stable, complet et bien maintenu. Cependant, il présente aussi quelques inconvénients : poids élevé, nombre conséquent de dépendances et une mauvaise « Developer eXperience » (= DX). Jérémy Derussé et Tobias Nyholm (Développeurs – Core Contributeurs Symfony) ont créé async/AWS pour apporter un SDK alternatif qui comble ces lacunes avec un niveau de qualité similaire. Jérémy Derussé débute ce talk en parlant de la DX et en listant les éléments que nous ne pouvons pas utiliser au niveau des composants de Symfony avec le SDK AWS directement (debug bar, maker bundle et auto-wiring). Par la suite, il dévoile un exemple simple de sf/http-client doté d’un code lisible et maintenable :
Jérémy aborde le sujet du kit SDK-AWS-PHP : bien que cette bibliothèque soit maintenue, testée et bien documentée, elle comporte d’autres points noirs, notamment concernant sa difficulté d’utilisation et l’illisibilité de son code. De son côté, Symfony utilise AWS (Messager SQS, Mailer SES, Notifier SNS) qui forme directement les calls via les endpoints d’amazon sans utiliser le SDK. Néanmoins, la communauté s’attend à un support plus performant, comme le prouve les éléments d’erreurs ci-dessous :
Jérémy explique que l’une des issues qui lui a posé quelques difficultés est le fait de ne pas utiliser le SDK AWS. Il était réticent à cette idée, car le SDK AWS est difficile à maîtriser et à intégrer au sein de l’écosystème Symfony. Thobias et lui ont donc décidé de créer un SDK : async/AWS. En amont, ils se sont demandés comment le maintenir et surtout, comment garantir que le SDK fonctionnera toujours. Ils se sont basés sur une véritable mine d’or dans le SDK AWS : la liste de toutes les opérations en JSON. Cela leur a permis de créer un générateur qui va construire les classes PHP avec ce fichier JSON. Les bénéfices générés par ce projet sont les suivants :
- Code auto-généré et lisible (auto-complétion),
- Si Amazon crée une nouvelle feature, il suffira de lancer le générateur,
- Mise à jour du repository avec une PR grâce à la mise en place d’une CI qui utilise les github action,
- Le code est maintenu en partie automatiquement.
De plus, Jérémy et Thobias se sont occupés du DX en utilisant le HTTP Client de Symfony et en mettant en place un code lisible et facile à maintenir. Cela permet de ne pas se poser la question de ce que l’on utilise (vs guzzle fonction async), mais aussi d’avoir la possibilité de l’utiliser en Async ou en Sync et de faire plusieurs requêtes en même temps :
Il est aussi possible d’utiliser le retryable HTTP Client, cela évite de réaliser un try/catch pour retenter la requête, puisque cela va s’exécuter automatiquement :
AWS a tendance à considérer un grand nombre d’éléments comme étant des erreurs 400. Cela est bloquant si l’on souhaite retenter certaines requêtes. Jérémy et Thobias ont donc établi une stratégie custom AWSRetryStrategy pour pallier cette problématique. En cas d’erreur 400, ils liront donc les messages et en fonction de ces derniers, ils vont retry ou non.
« Pied au plancher avec SymfonyTurbo »
Kévin Dunglas (créateur d’API Platform framework, des protocoles Mercure.rocks et Vulcain.rocks, membre de la Core Team Symfony) présente son talk sur Hotwire Turbo, une petite bibliothèque récemment publié par DHH, le concepteur de Ruby On Rails. Turbo offre la possibilité aux développeurs.euses de construire des sites web dont l’expérience utilisateur se rapproche de celle des Single Page Apps, sans devoir écrire une ligne de JavaScript. Dans la continuité de l’initiative Symfony UX, Kévin a conçu une intégration officielle de Turbo avec Symfony. Symfony Turbo permet donc de se débarrasser du JavaScript pour profiter pleinement des fonctionnalités offertes par Twig, sans faire de concession aussi bien au niveau des performances que sur l’expérience utilisateur.
Comment lancer un projet Symfony avec Turbo ?
Pour lancer un projet Symfony avec Turbo, il est nécessaire d’utiliser Symfony 5.3. Ensuite, il faut lancer le paquet : symfony-ux/turbo
Suite à cela, il est nécessaire de décommenter les tags de Webpack encore présents dans le template twig base.html.twig. Une fois que vous avez réalisé ces quelques manipulations, Turbo Drive est déjà prêt à l’utilisation ! Les Frames de Turbo ressemblent à des composants React / Vue. Vous avez la possibilité de mettre à jour un bloc sans devoir recharger toute la page. Voyez plutôt :
Il est aussi possible de réaliser du lazy loading avec les Frames utiles pour les caches, tout en indiquant des temps différents en fonction des blocs sollicités. Toutefois, Kévin précise qu’il est important d’avoir le même ID pour le Turbo-Frame.
Kévin fait ensuite un focus sur Mercure. Pour rappel, Mercure est un protocole permettant d’envoyer des mises à jour de données aux navigateurs web et autres clients HTTP d’une manière pratique, rapide et fiable. Il est particulièrement utile pour publier des mises à jour en temps réel de ressources servies par des API, vers des applications web et mobiles. Kévin montre un exemple du fonctionnement de Turbo Stream avec Mercure, tout en précisant que Symfony CLI inclut désormais Mercure Hub nativement. Pour le côté production, il est aussi possible d’utiliser les images Docker.
Avant de clôturer ce talk, Kévin effectue une interaction entre Turbo et Doctrine :
Peut-on dire que c’est la fin des framework JS ? Selon lui la réponse est non, car tout dépend de ce que l’on souhaite faire. Cependant, une chose est sûre : Symfony Turbo est une technologie particulièrement intéressante pour le E-Commerce !
« Deep dive into the form component »
Laurent Voullemier (Développeur Senior Symfony) démystifie le composant Form à travers ce talk. Le composant Form n’est pas forcément le composant le plus simple de Symfony. Cela se traduit par son grand nombre de FormType, qui ont chacun leurs spécificités, mais aussi par rapport à la « magie » qui semble à première vue se dérouler en interne. Le FormComponent a été créée suite à des travaux d’analyse sur une architecture back-end en se basant sur des niveaux d’abstractions dans le but d’obtenir :
- Des composants réutilisables,
- Des layers plus « hauts » afin d’y greffer des logiques poussées.
Comme précisé sur le schéma ci-dessus, CreateBuilder appelle createNamedBuilder, basé sur le block_type du formType. Si cela n’est pas défini, il utilise des guessers. Pour chaque FormType, nous avons deux guessers qui permettent d’auto-alimenter le formType de chaque field (on construit le père puis le form et ensuite tous les formFields).
« Des trésors cachés dans Symfony »
Nicolas Grekas (CTO Blackfire.io – membre de la Core Team Symfony), nous dévoile des features qui ne sont pas forcément annoncées sur le blog, mais qui peuvent s’avérer très utiles !
Il commence par le Kernel en nous le présentant comme un véritable couteau suisse (possibilité d’en faire une extension, d’utiliser le CompilerPass, etc.). Il continue sur les nouveautés qu’apporte PHP 8 et la future version de Symfony (5.3) avec l’introduction des Attributs, qui permettent de mettre fin au fichier de configuration YAML.
Nicolas expose ensuite plusieurs features, dont :
-
- Process :
‣ ExecutableFinder pour trouver le bon exécutable
-
- VarDumper :
‣ VarDumperTestTrait
-
- Validator :
‣ NotComprisedPassword
Nicolas précise que les différents éléments évoqués à travers ce talk proviennent principalement des contributions venant de l’extérieur ou de demandes émanant de la communauté, mais il n’y a pas de planification à l’avance.
« Cypress, le E2E moderne doit encore apprendre du passé »
Guillaume Loulier (Développeur Symfony) aborde Cypress, un outil dédié aux tests E2E (= End-to-End) et utilisé par de grandes entreprises telles que Disney, Github, Paypal ou encore Slack. Cypress est un framework orienté E2E disponible via Yarn, NPM et Docker. Il propose une syntaxe connue, simple et intuitive, ainsi que des raccourcis pour accélérer le processus d’écriture. Soutenu et développé par l’entreprise du même nom, Cypress a été lancé sous une licence MIT.
L’outil agit comme un wrapper autour de Chai, jQuery, Sinon et Mocha pour ne citer qu’eux. Il peut intercepter, mocker, décorer les requêtes (XHR/fetch..) et via son utilisation, l’UI peut entièrement être mise de côté pour accélérer les tests. Le débug est simplifié par des screenshots, des vidéos et un replay des étapes ayant échouées. Voici quelques caractéristiques supplémentaires de Cypress :
Cependant, Cypress ne comporte pas que des avantages et dispose aussi de quelques inconvénients :
- L’API est souvent remaniée / améliorée, ce qui peut introduire des BC breaks,
- Des fonctionnalités sont quelques fois amenées par des plugins peu/plus maintenus,
- Le débug de certaines erreurs n’est pas toujours simple.
Malgré cela, Guillaume recommande toutefois l’adoption de Cypress et ce, pour les raisons suivantes :
« Démarrer avec Symfony UX »
Titouan Galopin (SymfonyInsight Product Manager / CoreTeam Symfony UX) débute ce talk en expliquant qu’il existe deux types d’applications web :
- L’application dite « Traditionnel » (Symfony, Drupal..) qui fonctionne avec Html et les JavaScripts standards des navigateurs,
- L’application « Single Page App » (HTML construit en Javascript côté client) qui présente un intérêt UX intéressant.
L’inconvénient majeur du Single Page App réside dans le fait qu’il soit souvent nécessaire de reconstruire l’ensemble du site from scratch malgré les features proposées nativement (React/ Vue.js/ Angular). S’il est mal utilisé, cela peut engendrer une perte d’optimisation concernant l’UX de votre plateforme. Par défaut, le package d’installation de Symfony est très pauvre côté front, mais propose les outils suivants pour l’améliorer :
- Webpack : un bundler pour vous aider à terminer votre code et le compiler de façon à obtenir un seul et unique fichier final,
- Webpack Encore : une librairie pour utiliser Webpack avec Symfony dans les meilleures conditions.
Voici comment se présente l’architecture de Symfony avec Webpack Encore à ce jour :
Titouan met en lumière Stimulus, un framework qui ré-exploite ce qui est rendu dans la page. Issu de Ruby on Rails, Stimulus améliore uniquement le Html mais n’en gère pas l’intégralité. Titouan fait un parallèle entre Stimulus et un concept de base : les controllers.
L’utilisation de Stimulus permet au code de s’exécuter quand l’élément est trigger dans le lifecycle de l’élément tracké via la notion de « controllers ». Les controllers vont écouter des zones de la page (exemple : une div) et les scripts JS vont pouvoir piloter les interactions UX (cf. Symfony UX Turbo). Cela s’intègre dans le twig avec des annotations spécifiques :
Pour aller plus loin, Titouan fait un focus sur différentes commandes :
- Targets : permet de snipper des éléments HTML dans la zone écoutée,
- Actions : pour écouter les différents events,
- Values : donne un système de store et un état. Cela permet d’injecter les values renvoyées par les controllers Symfony dans le store de Stimulus via le twig. À noter que l’utilisation des helpers Twig permettent d’envoyer de la data encore plus facilement dans les stores de Stimulus.
Pour terminer ce talk, Titouan explique que Symfony UX est une librairie composée d’un grand nombre de fonctionnalités abstraites déjà développées, ce qui permet aux utilisateurs de les exploiter avec peu de configurations. Ce dernier effectue ensuite deux recommandations :
- Avoir un controller sur le body pour obtenir un store global,
- Avoir un controller API qui permet d’échanger le store entre les controllers.
« The New Testing Landscape : Panther, Foundry & More »
Cette conférence est présentée par Ryan Weaver (Symfony docs Lead) à propos de différentes librairies utiles pour réaliser des tests unitaires, d’intégrations ou fonctionnels. Tout d’abord, le Symfony Maker Bundle permet de générer les squelettes des différents tests :
Ryan nous présente ensuite la librairie: zenstruck/foundry, qui permet de créer des fixtures très facilement pour nos tests. Il a aussi mis en lumière zenstruck/browser, qui a pour objectif de nous faciliter la tâche et de simplifier nos tests. Voici un avant/après de l’utilisation de zenstruck/browser :
Ryan termine ce talk par un zoom sur symfony/panther, utilisé pour les tests fonctionnels, qui utilise un vrai navigateur (à contrario des WebTestCase). Grâce à son utilisation, nous pouvons donc tester notre page en conditions réelles (JavaScript, Ajax, auto-complétion, etc.)
Conclusion
Pouvons-nous dire que cette édition de SymfonyLive Online était un succès ? Oui ! L’événement a su proposer des conférences sur des thèmes diversifiés, permettant à sa communauté francophone de partager des connaissances toujours plus vastes. Malgré la distance, les intervenants ont su mener des talks intéressants, dynamiques, interactifs, tout en prenant le temps de répondre aux différentes questions des participants.
Merci aux équipes de Symfony pour l’organisation de cet événement et d’avoir permis à sa communauté de se réunir pour partager sa vision du développement web !
Vous avez un projet de développement E-Commerce ?
Spécialisé dans le E-Commerce depuis sa création en 2004, Dn’D est un partenaire de la solution OroCommerce. Attachées aux meilleures pratiques Symfony et PHP, nos équipes se tiennent à votre disposition pour vous accompagner dans le conseil, la conception et la maintenance de vos sites E-Commerce. N’hésitez pas à nous contacter via le formulaire ci-dessous !