Retour sur la SymfonyCon 2022

La semaine dernière, un mois après le Forum PHP, nous nous sommes rendus à Disneyland Paris pour assister à la SymfonyCon 2022, annoncée depuis la SymfonyCon Amsterdam 2019 et reportée à plusieurs reprises en raison du contexte sanitaire. Plus de 1300 participantes et participants se sont donnés rendez-vous à l'Hotel New York - The Art of Marvel pour assister à une trentaine de conférences réparties sur 3 scènes. Notre coopérative était venue en grand nombre pour à la fois tenir un stand (nous étions sponsors Gold), prendre la parole sur scène ou tout simplement monter en compétences sur des sujets variés et liés à l'écosystème Symfony. Voici le retour de notre équipe :

Jérôme Vieilledent est Product Manager User Experience chez Platform.sh. Il a commencé par nous donner une définition très générale de l’observabilité, avant de reconnaître qu’elle ne nous disait pas concrètement en quoi ça consiste. L’observabilité est un système où un groupe d’éléments interagissant (ou liés) en suivant un ensemble de règles forment un tout unifié. Il a noté l’analogie avec le code.

L’intérêt de l’observabilité est d’apprendre à partir des données extraites d’un external output des informations notamment sur la performance. La performance d’une application web a des conséquences directes sur les revenus d’une société. En effet 53 % des internautes quittent un site s’il met plus de trois secondes à charger. Améliorer les performances ne serait-ce que de 100 ms permettrait d’augmenter les taux de conversion de 7,1 %.

Plus un problème est diagnostiqué tard dans la chaîne "développement => test/staging => production", plus le coût sera important. Et il n’est pas possible d’améliorer ce qu’on ne sait pas mesurer. Les développeuses et développeurs web n’ont pas toujours les outils adaptés pour comprendre la cause profonde des ralentissements de leur application.

Différents outils servent des buts différents. L’analyse statique est le premier outil important en observabilité, c’est elle qui va permettre de diagnostiquer les problèmes présents dans le code, le tout sans écrire de tests. Parmi les outils d’analyse statique les plus utilisés dans l’écosystème PHP, on peut par exemple citer Psalm, PHPStan ou encore SymfonyInsight.

Néanmoins reste la boîte noire de ce qui se passe une fois que c’est en production. C’est là que les logs peuvent intervenir et pour cela les recueillir est fondamental. Il évoque Sentry, dont la société éditrice est présente sur le salon, un logiciel libre permettant de faire remonter les erreurs, y compris celles générées en production dans un outil centralisé auquel les développeurs ont accès.

Collecter des métriques est aussi indispensable au diagnostic des ralentissements d’une application web. L’APM (Application Performance Monitoring) est l’outil adapté à ce besoin.

Blackfire.io peut être classé dans les APMs. Il collecte des métriques à la fois grâce à un monitoring (fonctionnalité ajoutée il y a un peu plus d’un an) mais surtout grâce au profiling d’une application.

Jérôme a utilisé une métaphore très à propos en comparant la situation à celle de l’observation du trafic automobile d’une ville telle que Paris. Une vue sous la forme de carte nous permettra de savoir où et quand un ralentissement se produit. Par contre, il ne nous renseignera pas sur le pourquoi. Une street view par contre nous permettra par exemple d’identifier des travaux, donc la cause du ralentissement.

C’est l’enjeu du profiling : définir le pourquoi, à l’aide d’un outil tel que Blackfire.io. Il peut être utilisé en développement comme en production, où l’environnement n’est pas toujours à 100 % le même. Blackfire.io propose des actionable performance insights avec des détails en temps réel sur l’exécution d’une requête HTTP. On saura par exemple le nombre et le temps d’exécution des requêtes SQL.

En conclusion, Jérôme indique que l’observabilité et la stabilité comptent, et que même si la performance est importante, ce n’est qu’une partie du spectre.

Compte-rendu écrit par Hugo.

Stefan Koopmanschap est développeur PHP depuis 1997. Il utilise Symfony depuis la version 0.6 et est actuellement à la tête de son entreprise, Ingewikkeld, (traduction : “complexe”, “compliqué”) avec sa femme. Durant cette conférence, il partage les leçons qu’il a tirées de différents films Disney.

Le premier film dont il nous parle est La Reine des Neiges. Au début du film, Elsa a peur de ses pouvoirs suite à un accident qu’elle a provoqué. Elle est bloquée par sa peur jusqu’au moment où elle comprend qu’utiliser son pouvoir est la seule solution pour régler le problème auquel elle est confrontée. Les leçons à tirer de ce film sont donc : 

Le film suivant est Le Roi Lion. Alors qu’il est dans une situation critique, Simba trouve un système de soutien (et une famille) grâce à Timon et Pumba qui sont là pour assurer ses arrières et l’aider à grandir. L’idée ici est que parfois il faut chercher de l’aide, parfois l’aide arrive toute seule, mais dans tous les cas nous ne sommes pas seul·e·s. Notre entourage peut nous aider : 

Avec le double exemple de Toy Story et Hercule, Stefan nous explique l’importance de se fixer des objectifs, que l’objectif soit “Vers l’infini et au delà” comme Buzz l’Éclair, ou une suite d’étapes comme Hercule qui doit passer par ses douze travaux pour grandir/se trouver. L’important ici est de : 

Spoiler alert : les éléments à retenir sont les mêmes que pour la leçon précédente, dans un ordre légèrement différent. Pour illustrer cette leçon, il nous parle du film Cars, et de Flash McQueen. Personnage antipathique au début du film, Flash apprend de ses erreurs, se rend compte que l’objectif qu’il avait au début ne lui correspond plus, et se fixe un but qui correspond mieux à ce qu’il veut. 

Dans Monstres & Cie, Randall veut à tout prix être le meilleur, mais cette ambition le pousse à avoir des comportements qui causent du tort à la Monstropolis. Stefan Koopmanschap nous invite ici à ne pas se la jouer perso dans notre environnement professionnel : 

Avec Mulan, on revient un peu sur la première et la troisième leçon. Dans le film, l’héroïne ne se conforme pas aux attentes de sa famille. Elle choisit de se déguiser en homme pour pouvoir rejoindre l’armée et combattre. Même après avoir été découverte et exclue de l’armée, elle parvient à sauver l’empereur. Pour Stefan Koopmanschap, les leçons à tirer de Mulan sont : 

Pour terminer, Stefan Koopmanschap nous encourage à adopter des points de vue différents. Pour cela, il évoque La Belle et le Clochard, et Là-Haut. Dans les deux films, les protagonistes sont coincés dans des situations dont ils n’arrivent à sortir que lorsqu’ils adoptent un point de vue différent. Selon lui, ces deux films nous encouragent à : 

Dans sa conclusion, il nous rappelle que nous sommes justement entourés de pairs avec lesquels nous pouvons échanger, que ce soit pendant les conférences ou pendant les temps de pauses, et il nous invite à nous connecter aux autres.

Compte-rendu écrit par Natacha.

Pauline Vos est développeuse freelance à Amsterdam. Nous l’avions d’ailleurs invitée cette année à l’API Platform Conference 2022 (revoir sa conférence). Elle partage aujourd'hui quelques astuces pour utiliser Git plus efficacement.

Elle commence par nous rappeler les principes du Atomic commit, principes qu'elle a déjà présentés dans un talk passé. Un commit atomique est une bonne pratique permettant de profiter au maximum des possibilités offertes par Git. Pour résumer, c’est :

Les principaux avantages à faire des commits atomiques sont les suivants :

Pauline enchaîne en expliquant brièvement le concept de Detached HEAD dans Git. C'est une fonctionnalité qui permet de remonter dans l'historique des commits, tester des modifications, faire des commits mais sans modifier la branche de départ. Si on veut garder ces modifications, il faut créer une nouvelle branche.

Pauline nous présente ensuite la commande `git rebase -i`, ou rebase interactif. Le rebase interactif permet de réorganiser son historique local, via une interface intuitive. On peut, entre autres, y changer l'ordre des commits `pick`, s'arrêter sur un commit pour modifier son message (`reword`), fusionner plusieurs commits entre eux (`squash` ou `fixup`) voire supprimer certains commits (`drop`). Cela permet de garder un historique propre et aide à faire des commits atomiques.

Elle nous parle ensuite de la commande `git bisect`, qui permet de trouver le commit à l'origine d'un bug et nous montre un exemple d'utilisation. On apprend aussi qu'on peut utiliser `git bisect run path/to/script.php`, pour effectuer le bisect automatiquement. Ainsi, à chaque itération du `bisect`, le script donné en argument est exécuté. Le commit est alors considéré `good` si le script retourne le code de sortie `0`, et `bad` sinon. À la fin, la commande nous donne le premier commit pour lequel l'erreur est rencontrée. Combiné à `phpunit`, il devient alors très facile de trouver l'origine d'un bug. Les commits atomiques démontrent ici leur intérêt.

Mais que faire si le bug remonté n'est pas couvert par un test ?

Une solution en trois étapes :

Pauline nous partage une petite astuce permettant d'utiliser facilement `git bisect` dans ce cas-là. Il suffit d'écrire un test mettant en évidence le bug, le committer puis faire appel à un rebase interactif pour déplacer ce commit dans le passé. On peut alors facilement utiliser `git bisect` pour trouver l'origine du bug ! Plus besoin de fouiller dans le code pour comprendre d'où il vient !

Pour finir, Pauline nous présente la commande `git reflog`, permettant d'accéder à l'historique des actions effectuées sur le repository (commits, rebases, checkouts...). On peut ensuite se déplacer dans cet historique comme on le ferait dans l'historique des commits (via `git checkout` par exemple). Cela permet entre autres d'annuler une opération qui se serait mal passée, comme un rebase : "Everything you do in Git can be undone!".

Compte-rendu écrit par Xavier.

Fred Plais est le créateur de Platform.sh et est un citoyen français vivant aux États-Unis. Leah Goldfarb est Environmental Impact Officer chez Platform.sh et est une citoyenne américaine vivant en France. 

Fred introduit la conférence en nous racontant la fameuse histoire du colibri dont la morale est que chaque petit geste, même apparemment insignifiant, compte. Leah introduit son propos en nous invitant à réfléchir sur l’impact climatique du PHP à l’échelle mondiale. 

Après avoir donné quelques données chiffrées sur les émissions de CO2 dans la tech, Leah nous invite à prendre un peu de hauteur et explique que si l’effet de serre est quelque chose de positif, car sans lui notre belle planète bleue ne serait qu’une géante de glace, le fait qu’il y ait eu une augmentation de 40 % des émissions depuis l’ère pré-industrielle fait craindre un fort emballement des températures et il est urgent d’agir.

Même par pure préoccupation économique, il est plus rentable d’agir maintenant que plus tard, car plus le temps va passer, plus le coût nécessaire pour “minimiser” l’impact du changement climatique va progresser.

En tant qu'Environmental Impact Officer chez Platform.sh, Leah met en avant que la préoccupation climatique de la plateforme est sans arrière pensée, une vraie volonté de minimiser l’impact du Cloud sur le climat, volonté présente depuis les débuts.

L’objectif affiché est de proposer une façon plus verte d’héberger des données.

Platform.sh s’est doté d’un outil appelé le M.O.D.E. Framework pour : 

Measure : mesurer l’impact carbone de la plateforme est réalisé par un organisme indépendant, Greenly, suivant le protocole GHG (Greenhouse Gas Protocol), protocole international proposant un cadre pour mesurer, comptabiliser et gérer les émissions de gaz à effet de serre. La plus forte source des émissions carbone de la plateforme Cloud est, sans surprise, tout ce qui a trait aux centres de données et aux ressources qu’on y trouve (principalement des serveurs).

Optimize : en comparaison avec des machines virtuelles classiques ou une infra on premises, le Cloud offre une meilleure utilisation des ressources (les serveurs ont le maximum de leurs ressources utilisées).

Deploy : le meilleur levier évoqué par Leah reste la réduction et la consommation énergétique et l’utilisation d’une électricité décarbonée. Ça passe par le choix de centres de données dans des régions “plus vertes”. Par exemple, l’électricité française est beaucoup moins carbonée que l’électricité polonaise, et le facteur est impressionnant, est évoqué un ratio de 1 à 10. Il faut, dans cette dynamique, offrir une information complète et transparente aux clients des plateformes Cloud pour qu’ils puissent prendre une décision éclairée.

Educate : l’audit carbone reste dans ses balbutiements, et il faut bien reconnaître que ce qui semblait être de bons indicateurs il y a quelques années, ne l’est pas forcément autant aujourd’hui au fur et à mesure que les modèles évoluent. Il faut faire un vrai travail d’éducation autour des problématiques du climat.

Cette conférence était très intéressante car elle montre qu’il y a de vrais gains possibles et que le milieu de la tech a une vraie responsabilité et une vraie carte à jouer dans ce domaine. On pourra néanmoins regretter que la problématique environnementale ne soit traitée qu’au travers du prisme du climat. L’impact environnemental du Cloud a aussi trait aux ressources physiques utilisées pour produire les serveurs, les infrastructures réseau, etc.

Compte-rendu écrit par Hugo.

Titouan Galopin, membre de la core team Symfony, explique qu’il est important de connaître son contenu : quand on crée un site ou une application, on doit savoir ce qu’il y aura dedans. C’est important à la fois pour choisir la bonne architecture et le bon éditeur de contenu.

Il donne ensuite une liste de questions à se poser :

Il nous explique que les réponses à ces questions sont à la fois techniques et humaines. Il nous dit aussi que les éditeurs de contenu représentent un des challenges UX les plus complexes.

Une fois les questions initiales posées, nous passons aux problèmes de sécurité. Les éditeurs de contenu présentent un gros risque en terme de sécurité : 

Après avoir énuméré les risques, Titouan donne des solutions pour implémenter la sécurité. La plus simple selon lui est l’utilisation du filtre Twig `escape` (ou `htmlentities`) dans les cas où l’on n’a pas besoin d’accepter du HTML. Il recommande d’utiliser ce filtre à chaque fois que c’est possible.

Pour les cas où l’on doit accepter du contenu enrichi, il recommande d’utiliser le composant Symfony HTML Sanitizer, qui : 

Le composant peut s’utiliser comme un service, dans un formulaire et comme un filtre avec Twig. Au niveau de la configuration, on peut utiliser la configuration par défaut ou faire une configuration personnalisée en précisant quels sont les balises HTML, liens et médias autorisés et ceux qui sont interdits.

On arrive ensuite au choix de l’éditeur de contenu. Celui-ci doit correspondre à nos besoins techniques et UX. Titouan nous donne plusieurs pistes.

La première est la plus basique : un simple `textarea`, qui présente l’avantage d’être facile à utiliser par tout le monde. Cependant on sera limité en termes de stylisation. On passe ensuite à l’option Markdown couplé à CodeMirror, très bien pour des utilisateurs techniques, mais pas utilisable par du grand public. Enfin, nous avons l’option WYSIWYG (What You See Is What You Get) : facile à utiliser par tout le monde, mais qui requiert une librairie JavaScript assez complexe.

Cependant quel que soit le choix, le contenu généré est du HTML, ce qui rend sa manipulation difficile. Pour Titouan, la solution se trouve dans les éditeurs block-based : stocker le contenu sous forme de blocs JSON, le HTML étant rendu seulement lors de l’affichage. Le JSON est facile à manipuler, permet d’afficher du contenu hors-ligne et facilite la migration de contenu lorsque les éditeurs sont mis à jour.

Il donne en exemple Quill Rich Text Editor. Cet éditeur utilise des Deltas, des objets JSON qui stockent le contenu et les modifications qui lui sont appliquées. D’un point de vue “sécurité”, les blocs doivent être échappés (Twig/htmlentities). Quill s’implémente dans Symfony de façon similaire à CKEditor. Le contenu généré est stocké en base de données en tant que JSON. Pour finir il nous montre comment Symfony UX et Mercure permettent de faire du live-editing. 

En conclusion, pour des besoins simples, l’option “plain-text + escape” est suffisante. Pour des utilisateurs techs, Markdown + HTML Sanitizer avec un éditeur de code est une option efficace et flexible. Dans les autres cas, il est recommandé de choisir l’option “ block-based editor + sanitization”.

Compte-rendu écrit par Natacha.

David Buchmann travaille chez Liip, une agence web basée en Suisse. Il nous parle d'un cas d'usage pour lequel Symfony Messenger a permis d'améliorer la maintenabilité et la performance d'une application : le développement d'une API pour une enseigne suisse de grande distribution. Cette API comporte énormément de données en tous genres (produits, listes d'ingrédients, stocks...) et de nombreuses opérations y sont réalisées quotidiennement.

Leur première approche a été d'utiliser des tâches cron. Cependant, ils se sont vite heurtés à différents problèmes :

Ils ont ensuite essayé de découpler l'application en encapsulant les différentes actions effectuées sur le produit dans des messages. Cela leur a permis de mettre en place des files d'attente pour le traitement des opérations. Les principaux avantages sont les suivants :

Ils ont ensuite pu améliorer les performances en séparant les tâches lourdes en plus petites tâches. Concrètement, le traitement d'un message est découpé en plusieurs opérations, retournant à chaque fois un autre message, qui est envoyé à un autre processeur. On obtient ainsi une chaîne de messages, tous traités de manière asynchrone.

David nous explique ensuite qu'ils auraient pu atteindre le même objectif en découpant l'application en microservices. Cependant, cela aurait augmenté la complexité du développement. En effet, ils ont plus de trente types de messages et leurs processeurs associés. En utilisant des microservices, ils auraient eu à développer, maintenir et héberger une trentaine d'applications Symfony.

L'intérêt de Messenger réside dans le fait que c'est découplé. On sépare l'émission du message, la gestion de la file d'attente et le traitement du message. On peut ainsi héberger séparément ces opérations. De plus, le traitement des messages étant asynchrone, les opérations lourdes ne vont pas augmenter le temps de réponse pour les utilisateurs. Enfin, ce système est résilient et fiable. Si l'application en charge du traitement du message est hors service, les messages resteront dans leur file et, si un traitement échoue, le message peut être renvoyé automatiquement.

Bien que des alternatives existent, ils ont choisi d'utiliser le composant Symfony Messenger. Les principales caractéristiques de Messenger qui ont influencé cette décision sont :

David termine la conférence en expliquant brièvement l'architecture et le fonctionnement de Symfony Messenger.

Compte-rendu écrit par Xavier.

Alexander Turek est développeur freelance en Allemagne et membre de la core team Symfony. Il intervient sur scène pour nous expliquer comment moderniser une vieille application en utilisant ce framework.

Pourquoi pouvons-nous avoir besoin de moderniser ? Notre application peut avoir été codée il y a 20 ans. Depuis, le nombre d'utilisateurs, le trafic, la quantité de données stockée peuvent avoir augmenté considérablement. Cependant, au fil des années, s'il n'y a pas eu de maintenance, on accumule de la dette technique. Si on ne fait rien, on peut se retrouver avec des failles de sécurité, et on serait bloqué sur d'anciennes versions des langages. On n'aurait également pas la possibilité de moderniser l'infrastructure (pour passer sur du Kubernetes, par exemple). On pourrait envisager de réécrire l'application de zéro, mais cela demande un budget énorme, sachant qu'il y aura toujours de la maintenance et des ajouts de fonctionnalités à réaliser sur l'ancienne application. Sinon, on peut ré-écrire des petits bouts qui peuvent être ré-intégrés directement dans l'application.

Une approche simple serait de créer une application Symfony. Le front controller va décider si la requête peut être traitée par Symfony ou doit être envoyée à l'ancienne application. Concrètement, on appelle la méthode `Kernel::handle()` et, si le routeur renvoie une erreur 404, la requête est transférée à l'ancienne application. On peut également écrire un `LegacyController`, qui va s'occuper d'appeler l'ancienne application. On peut ainsi migrer petit à petit vers la nouvelle application :

On peut également utiliser le kernel Symfony dans l'ancienne application, en le définissant comme variable globale dans le front controller. De cette manière, on peut s'en servir pour accéder aux services de Symfony, comme par exemple la connexion à Doctrine. Ainsi, on peut utiliser des nouveaux services dans l'ancien code, avant de l'avoir migré dans un controller Symfony :

Enfin, il y a la problématique de l'authentification. En général les anciennes applications vont stocker une représentation de l'utilisateur dans la session. Il faut donc pouvoir détecter cette authentification depuis l'application Symfony. Pour cela, on peut écrire un Authenticator qui va faire le lien entre l'ancien système de login et le composant Security de Symfony.

Compte-rendu écrit par Xavier.

La SymfonyCon a été l'occasion pour nous de rencontrer (et croiser des ami·e·s de longue date) la communauté Symfony internationale. Nous avons eu la chance d'échanger avec beaucoup de participantes et participants sur notre stand qui soit nous posaient des questions sur notre fonctionnement en tant que scop, ou alors qui voulaient de plus amples informations sur le framework API Platform ou sur notre toute nouvelle offre Cloud.

Nous avions également la chance d'avoir deux coopérateurs conférenciers de l'événement. Bravo à Robin Chalas pour sa sélection et son talk sur OAuth. Le replay de cette conférence sera très prochainement disponible sur les comptes Symfony Connect des personnes inscrites à l'événement. De son côté, Kévin Dunglas a présenté FrankenPHP devant une salle comble.

Sur notre stand, les participantes et participants pouvaient jouer (spoiler: pour la dernière fois) au Lucky Webby pour tenter de remporter des lots inédits tels que nos mugs FrankenPHP :

Nous étions dévalisés à peine le second jour démarré ! Un grand bravo à toute l'équipe d'organisation pour cette édition remarquablement organisée malgré l'important flux de visiteurs. Nous vous donnons rendez-vous l'année prochaine à Bruxelles !