Retour sur le Forum PHP 2021 (partie 2)

Après la publication du premier volet du dernier Forum PHP, nous vous invitons dès à présent à découvrir la suite de notre compte rendu !

Frédéric Bouchery commence sa conférence avec une introduction sur le fonctionnement des différents aspects de la mémoire. On rentre dans le vif du sujet et il nous présente comment, dans un premier temps, il a utilisé des règles personnalisées PHPStan afin de vérifier des normes de conception du code.

En effet PHPStan est extensible et permet d'ajouter des règles d'architectures spécifiques. Celles-ci peuvent faciliter les relectures de code puisque certains manquements aux règles de conception "maison” peuvent donc être détectés avant même la création d'une pull request. On automatise ainsi au maximum afin que le relecteur puisse se concentrer sur ce qui est important.

Ces règles permettent de vérifier des ADR (Architectural Decision Records) de manière automatique, et donc de les documenter et renforcer la “mémoire” du projet. 

Il nous présente certaines de ces règles. Notamment, la vérification de certaines bonnes pratiques Symfony comme le fait qu'un contrôleur étende la classe AbstractController ou encore que celui-ci soit bien déclaré comme final. 

Pas totalement satisfait du résultat, il s’est demandé s’il pouvait transformer ces règles PHPStan en tests unitaires. Il a commencé à travailler sur un nouvel outil d’analyse spécifique à leurs besoins puis a donc transformé chacune des règles PHPStan en tests unitaires. Cette manière de faire s’est révélée plus souple, plus flexible et plus rapide à l’implémentation. Ici, on ne teste pas le fonctionnement du code, mais la manière dont il est écrit.

Ce système a même été étendu pour mettre en place des rappels automatiques comme le fait de ne pas oublier de migration de base de données si le modèle a changé.

Bonne nouvelle : l'outil d'analyse que Klaxoon développe dans ce cadre est voué à être publié sous licence libre dans les prochains mois. Vu l’appétence de la communauté PHP pour les outils d’analyse statique, il ne fait pas de doute que cette bibliothèque devrait rencontrer son public.

Compte rendu rédigé par Loïc.

Robin Chalas et Mathias Arlaud, tous deux coopérateurs et contributeurs entre autres à API Platform, nous ont prouvé qu'il était possible d’utiliser le framework en DDD, contrairement à l'approche RAD qui en est faite habituellement.

Le DDD, ça passe d'abord par une manière de structurer son code et de le nommer, de sorte à s’approcher au plus près possible d’un vocabulaire commun avec le métier.

Dans ce qu'ils nous présentent, c'est fait via une architecture hexagonale où plusieurs strates sont créées, permettant de séparer le code et de limiter les intéractions entre les différentes strates, en passant par la couche "domain" contenant le code métier (typiquement les modèles), jusqu’à la couche "infrastructure" permettant d'interagir avec l’extérieur (typiquement les contrôleurs ou la DB). Ceci permet d’avoir un code mieux isolé et donc plus facilement testable, plus résistant aux changements, et moins dépendant du framework ou des technologies utilisées.

Dans sa version la plus connue, API Platform utilise les attributs PHP (anciennement les annotations), afin de lier nos entités à leur représentation REST ainsi qu’à la base de données. Mais ces configurations peuvent être déportées vers la couche infrastructure qui est la seule pouvant dépendre d’API Platform.

Pour découpler notre application plus encore, ils nous suggèrent de créer nos opérations de récupération et création dans des Queries et des Commands, qui seront dispatchées grâce au composant Messenger, et paramétrées grâce à des Providers et Persisters customisés.

Bien entendu, si cette architecture présente un énorme avantage en termes de testabilité et scalabilité, elle n’est pas à utiliser pour des petits projets, sans quoi la complexité peut vite prendre le dessus sur la simplicité. Si le sujet vous intéresse, vous êtes bien évidemment invités à nous rejoindre au workshop sur la question, qui aura lieu le 25 novembre à Lyon ! Si vous souhaitez consulter leurs slides, c'est par ici !

Compte rendu rédigé par Élise.

Sofia Lescano nous a présenté les méthodes d’améliorations techniques utilisées chez Bedrock, et l’importance d’y consacrer du temps en tant qu’équipe.

Elle a notamment fait un parallèle entre un projet technique et un appartement en colocation où plusieurs personnes vivraient ensemble, chacune s’occupant de l’aménager (créer de nouvelles features) et de l’entretenir (améliorer la qualité du code et des outils).

Concrètement, BedRock a choisi de se réunir toutes les deux semaines afin de parler des sujets qu’il serait intéressant de travailler : qu’il s’agisse de remettre à jour quelques dépendances, d’améliorer l’alerting, de passer en DDD, de tester le MOB Programming… 

Chacun des membres de l’équipe, quel que soit son niveau, est invité à préparer un sujet qu’il présentera à ses collègues, sur lequel chacun pourra travailler par la suite. Bien entendu, le PO est incité à se joindre à la réunion, afin de bien faire comprendre les problèmes éventuels causés par la dette technique qui s’accumule.

On retiendra cette citation, qui, espérons saura convaincre tout un chacun :

Compte rendu rédigé par Élise.

Kévin Dunglas a présenté la future orientation du noyau d'API Platform dans sa version 3, qui sera basé sur une architecture dite "ESA", pour Edge Side APIs. La partie frontend du framework API Platform se base déjà sur l'architecture Jamstack (JavaScript API Markup), qui permet d'optimiser le rendu, les performances et de mieux scaler l'application notamment en pré-générant le maximum de fichiers statiques qui seront servis sur des CDN proches des utilisateurs.

Après un rappel sur le fonctionnement de REST ainsi que du fonctionnement du cache côté serveur et côté client dans le web aujourd'hui, Kévin a présenté le concept des Edge Side APIs qui s'inspire largement de tout cela et qui vient solutionner les problèmes existants.

L'idée est de s'appuyer sur les fonctionnalités des navigateurs modernes ainsi que des dernières versions 2 et 3 du protocole HTTP afin de minimiser les échanges de données entre client et serveur. En privilégiant un échange de ressources atomiques (et non plus imbriquées) qui garderont du lien entre elles grâce aux fonctionnalités Hypermedia (présentes depuis le départ dans API Platform), il devient alors possible de pré-générer les réponses de l'API en des morceaux unitaires faciles à mettre en cache, à invalider en cas de modification, et à stocker dans des CDN proches des utilisateurs.

Les fonctionnalités de preload/prefetch et de mise en cache des navigateurs web seront alors entièrement mises à contribution pour apporter une expérience utilisateur optimale tout en minimisant les échanges et les transferts de données inutiles.

Plus de cache, moins de transferts, dans une application distribuée : on optimise alors grandement les performances, la scalabilité, l'expérience utilisateur, la fiabilité de notre application, et le tout en consommant moins d'énergie !

Cette architecture peut être implémentée dans n'importe quel langage tout en respectant les principes de REST, et sera au cœur de la version 3 d'API Platform ! Découvrez dès à présent ses slides.

Compte rendu rédigé par Marion.

Très bonne présentation de Benoit Viguier sur l’une des fonctionnalités phare de PHP 8.1 : les fibers.

Les fibers ajoutent le support natif de l’asynchrone à PHP.

Historiquement, PHP permet uniquement d’écrire du code synchrone : dans une fonction, l'exécution s’arrête jusqu’à ce qu’un résultat soit disponible pour le retourner. Dans les cas des entrées / sorties (utilisation du réseau, accès disques…), cela peut prendre du temps et nuire à la performance des applications.

Une autre approche existe dans d’autres langages (pensez aux promesses et à async/await en JavaScript) et même en PHP via Swoole, AMPHP ou encore ReactPHP : la programmation asynchrone. Cette approche permet d’effectuer les I/O de manière concurrente, et ainsi - dans certains cas - d’améliorer drastiquement la performance.

Les fibers abordent le problème de manière différente de ce que permet JavaScript en tentant d’éliminer la distinction entre fonction synchrone et asynchrone. A la place, la fonctionnalité introduit une nouvelle classe native, Fiber, qui permet d’interrompre l'exécution d’une fonction, et de la reprendre (multitâche coopératif). L’intérêt de cette approche et qu’il devient possible et même facile d’utiliser les (très nombreuses) bibliothèques conçues pour fonctionner de manière synchrone comme l’ORM Doctrine ou encore Symfony… de manière asynchrone !

Benoit nous a présenté en détail cette nouvelle API, puis à dévoilé un nano framework qu’il a réalisé pour l’occasion : Slip.

Il a également introduit le projet RevoltPHP, une boucle d'événement utilisant sur les fibers co-maintenue par notre coopérateur Saif Eddin Gmati.

Rappelons que PHP 8.1 est déjà disponible en version RC (testez le !) et que sa version stable devrait être publiée courant décembre.

Compte rendu rédigé par Kévin.

Une super présentation de la part de David Négrier, CTO de The Coding Machine ! David nous remet en situation : le COVID nous tombe dessus, c’est le début du confinement, tout le monde est en garde à vue à domicile (vous vous souvenez de la fameuse auto-attestation nécessaire pour aller chercher son pain ?). Nos sociabilités sont réduites à néant pour “raison sanitaire”.

Pour briser l’isolement et essayer d’aider comme elle peut, l’équipe de The Coding Machine décide d’organiser un hackathon. Au fur et à mesure, une idée vient à David : pouvoir revivre des moments “machine à café” sans risquer de se prendre 135 € d’amende en cas de mauvaise rencontre sur la route du bureau !

Pour celà, il se met en tête - avec quelques collègues - de coder un jeu vidéo en 3D isométrique reproduisant leur bureau fantasmé dans un style “japonisant”. Dès que deux joueurs (ou plus !) s’approchent, une visio conférence apparaît dans la fenêtre du jeu. WorkAdventure était né ! Enfin tout du moins le prototype, parce-que c’est après que les choses se corsent !

David nous détaille les essais, les erreurs et les succès qui ont ponctué l’aventure, et nous découvrons ainsi l’architecture actuelle de WorkAdventure.

Le jeu a été réalisé en TypeScript à l’aide du moteur Phaser. Il est possible de créer facilement ces propres cartes grâce à l’éditeur Tiled. Les positions des “joueurs” sont envoyées en temps réel grâce au protocole WebSocket via Socket.io et enfin, la vidéo est gérée avec WebRTC grâce aux composants et bibliothèques fournies par Jitsi. David revient en détail sur le fonctionnement de WebRTC - qui permet de faire communiquer directement des navigateurs en pair à pair - et sur les subtilités de ce protocole. Les choses se compliquent dès que l’on veut pouvoir contourner les pare-feux d’entreprise qui bloquent UDP ou que l’on souhaite pouvoir regrouper plusieurs personnes dans une même visio. David nous détaille tous les composants nécessaires d’une manière très claire et instructive. Cerise sur le gâteau, WorkAdventure est disponible sur GitHub sous licence “source-available” (AGPL avec Commons Clause) !

Mais l’histoire ne s’arrête pas là. WorkAdventure a été utilisé par l’AFUP pour organiser le Forum PHP 2020 en ligne. Suite à ça, la communauté d’utilisateurs et de développeurs a augmenté de manière exponentielle. De nombreuses autres conférences ont utilisé l’outil. Les besoins en extensibilité se sont fait sentir. WorkAdventure est maintenant une véritable application REST permettant de charger des cartes (contrainte “interface uniforme” de l’architecture REST) et même des plugins via un astucieux système d’iframes (contrainte “code à la demande”) à la volée !

WorkAdventure, c’est aussi une success-story entrepreneuriale. Le logiciel est disponible en version SaaS. Pour réaliser le système de paiement et d’abonnement sans y passer trop de temps (mieux employé à développer le jeu lui-même), David a utilisé Laravel Spark.

Compte rendu rédigé par Kévin.

Encore une fois (et depuis deux décennies désormais) l'AFUP a réussit à concevoir avec brio un programme innovant, paritaire, varié, et cela avec une organisation admirable. Bravo à toute l'équipe ! Nous avons apprécié retrouver l'ambiance conviviale et chaleureuse bien connue de ce rendez-vous, retrouver les membres du staff qui ont toujours disponibles pour nous renseigner ou papoter avec bonne humeur. N'oublions pas qu'en addition de leur seule salariée, ils sont tous bénévoles (deux de nos coopérateurs sont d'ailleurs très actifs au sein de cette association : Cécile Helary est la présidente de l'AFUP depuis début 2020 et Alan Poulain fait partie du pôle de sélection des conférences).

Enfin, dernier point : bien que le Forum PHP soit par définition dédié aux développeurs·ses PHP, nos coopérateurs·trices spécialisés en JavaScript ont également apprécié ces deux journées de talks ! Pouvoir alterner conférences tech ou plus généralistes leur a permis de s'y retrouver et d'apprendre beaucoup. Nous attendons désormais avec impatience le Forum PHP 2022 prévu les 13 et 14 octobre car nous avons découvert où il se déroulera lors de la keynote de clôture : Disneyland Paris !

À bientôt !