Retour sur l'API Platform Conference 2024 - jour 2

Voici la suite de notre compte-rendu des sujets donnés à l'API Platform Conference 2024, qui s'est déroulée les 19 et 20 septembre derniers à Lille et en ligne. Pour rappel, notre retour sur les conférences données le premier jour se trouve sur cette page. Bonne lecture !

Caddy Server, c'est LE serveur par défaut de la distribution d'API Platform depuis maintenant plus de quatre ans. Pour son retour sur la scène de l’API Platform Conference, Matt Holt nous a présenté les principaux points de latence qui existent sur une infrastructure, notamment la démultiplication des briques logicielles. Il nous a invité à considérer PHP comme une extension du serveur (à l'instar de nos vendors qui agissent telles des extensions du PHP) pour réduire le nombre de briques et d'échanges réseaux. Pour illustrer ce postulat, Matt évoque FrankenPHP, qui est lui-même une extension du serveur web Caddy.

Il nous a ensuite rappelé que toute la configuration du serveur s’effectue via un seul fichier JSON, ce qui la rend à la fois très simple et fiable. En particulier, puisque c'est une API REST qui permet de manipuler cette configuration, il est tout à fait possible de la rendre accessible à distance, et de restreindre son accès à toute ou partie de celle-ci aux utilisateurs, grâce à une granularité fine des droits.

Pour finir, il faut noter l'excellente fonctionnalité de TLS on-demand, qui offre la possibilité de créer et renouveler automatiquement des certificats, mais aussi de porter la validation de certificats à l'aide de son propre serveur ACME CA, par exemple pour sécuriser un réseau privé.

Imen Ezzine, développeuse chez SensioLabs, a présenté une méthode pour tester une API externe sans utiliser de mocks, en se basant sur une application Symfony connectée à trois APIs (signatures, facturation, stockage).

Elle a comparé différentes approches : tester l'API réelle, utiliser un environnement dédié ou une sandbox, virtualiser l'API localement, et utiliser des mocks. Chaque option présente des avantages (réalisme, performance, isolation) et des inconvénients (dépendance externe, complexité, écart avec la réalité). Pour surmonter ces limitations, Imen a introduit PHP-VCR, un outil qui enregistre les requêtes et réponses HTTP pour les rejouer lors des futurs tests. Elle a détaillé la configuration de PHP-VCR, les différents formats et modes de stockage, ainsi que les hooks comme Stream Wrapper et CURL.

Les avantages de PHP-VCR incluent des tests plus rapides, indépendants de l'API, avec la possibilité d'inspecter et de détecter des requêtes inattendues. Enfin, elle a abordé la maintenance, notamment la mise à jour des cassettes, leur versionning, et leur nommage sémantique.

Lors de sa troisième participation à la API Platform Conference, Smaïne Milianni a abordé le sujet du code legacy et comment s'en sortir. Il a rappelé que le code legacy peut être désuet mais toujours utile, ou bien difficile à maintenir en l'absence de tests.

Pour éviter de tomber dans le legacy, il recommande de bonnes pratiques : écrire des tests, utiliser des outils d’analyse de code comme PHPStan et Psalm, effectuer des revues de code régulières, maintenir les dépendances à jour et documenter. Les tests doivent être rapides, isolés, répétables, et auto-validants.

L'architecture applicative est essentielle pour bâtir un projet solide. Smaïne met en garde contre certaines mauvaises pratiques, comme l’utilisation excessive de tableaux clés/valeurs ou des méthodes trop longues. Des outils comme Composer et des bots peuvent faciliter la gestion des dépendances.

Il a également présenté des méthodes pour refactoriser le code legacy, telles que la méthode 'Mikado' et le 'Golden Master Testing', avant de conclure sa conférence en affirmant que le cycle idéal pour gérer le legacy consiste à auditer, documenter, tester, améliorer et monitorer le projet.

Florian Engelhardt, développeur chez Datadog, est venu présenter son approche du 1 Billion Row Challenge en PHP. Il s'agit d'un challenge en ligne consistant à écrire un script capable de traiter le plus efficacement possible un fichier texte contenant 1 milliard de lignes. Quelques contraintes : n'avoir qu'un seul fichier source et ne pas utiliser de dépendance externe !

Son premier essai, une simple boucle lisant le fichier ligne par ligne grâce à la méthode fgetcsv(), traite le fichier en 25 minutes ! L'utilisation d'un profiler lui permet d’identifier quels traitements consomment le plus de temps. Sa première optimisation consiste à utiliser les méthodes fgets() et substr() à la place de fgetcsv(), car cette dernière implémente plusieurs fonctionnalités coûteuses dont il n'a pas besoin ici : ces changements réduisent de cinq minutes l’exécution ! Après plusieurs optimisations plus ou moins techniques (éviter le type juggling, activer l'OPcache et JIT, compiler PHP avec un plus haut niveau d'optimisation…), Florian a finalement réussi à créer un script qui traite 1 milliard de lignes en seulement 12,27 secondes 🚀 !

Il a terminé sa conférence en expliquant que les optimisations apportées sont  rarement nécessaires dans de vrais projets, et que dans certaines situations, 25 minutes de traitement peuvent être tout à fait acceptables (par exemple dans un script de migration qui ne serait exécuté qu’une seule fois). Le fin mot de cette histoire : PHP n'est pas si lent qu'on le dit (et n'est toujours pas mort) !

Fabien Papet, lead développeur et DevOps chez Sydev, a profité de sa première conférence pour nous présenter la construction d’un moteur de recherche basé sur Elastica, Symfony et sur API Platform.

Lors de son talk, Fabien a présenté plusieurs projets de son entreprise, partageant tous la nécessité d'un moteur de recherche centralisé pour effectuer des recherches par filtres ou critères multiples, avec des contraintes de priorisation, de confidentialité et de gestion de volumétrie. La solution repose sur des providers personnalisés, car les providers Elasticsearch d'API Platform ne supportent pas l'API count ni la librairie Elastica. 

Pour y remédier, ils ont développé leur propre provider Elastica, réutilisable dans d'autres projets. Fabien a justifié ce choix par les avantages de la librairie Elastica, notamment l'auto-complétion et l'intégration avec symfony/http-client. Il a fait une démonstration en live coding, et a conclu en mentionnant les options futures : intégration avec Elastically, création d’un package ou évolution des providers d'API Platform. Une démo est disponible sur son dépôt GitHub.

Boas Falke, développeur chez bitExpert AG, est venu présenter en vingt minutes son expérience avec FrankenPHP et sa capacité d'encapsuler toute l'application PHP dans un binaire. Il nous a expliqué qu'avec un peu de configuration, il est assez facile d'obtenir de quoi déployer un exécutable, ce qui se révèle très pratique pour des environnement contrôlés, au sein desquels il n’est par exemple pas possible de discuter avec l'extérieur ni d’installer des dépendances.

En revanche pour le déploiement de mises à jour, il n'est pas possible de soumettre des patch et de modifier à chaud le code extrait sur le disque afin d’éviter les downtimes. Boas a néanmoins insisté sur la capacité de FrankenPHP à s'arrêter gracieusement le temps de basculer d'un exécutable à un autre. Avec une bonne gestion des processus (PM2, Supervisor, etc.), les mises à jour peuvent s’effectuer sans trop de soucis et une coupure minime.

Nicolas Grekas est membre de la core team Symfony, sa conférence s’adressait principalement aux développeurs de bundles Symfony, afin de leur expliquer la bonne manière d’injecter des clients HTTP pour consommer des API dans leurs bundles.

Il a notamment expliqué comment configurer son projet avec Composer pour que les services restent agnostiques en termes de client HTTP afin que l’utilisateur final puisse choisir son client HTTP préféré s’il le souhaite, voire que le bundle sélectionne lui-même un client HTTP par défaut qui correspond à ses besoins. 

Pour ce faire, Nicolas nous a présenté le composant discovery dont le rôle est de sélectionner le client HTTP adéquat pour le bundle sans intervention de l’utilisateur. Ce composant est capable de trouver le client HTTP (tel que Guzzle) dans Packagist, de vérifier qu’il fournit bien toutes les fonctionnalités requises, de l’installer et de le configurer à la volée.

Adrien Guernier est développeur chez Marmelab, il a notamment contribué au refacto du projet api-platform/admin. Pour réaliser ce refacto, le projet étant assez complexe à appréhender, l’idée était de d’utiliser un Storybook pour développer les composants, ce que faisait déjà Marmelab sur marmelab/react-admin (un projet lui-même basé sur api-platform/admin).

Son talk a ainsi débuté avec une présentation de Storybook, en s’appuyant sur l’exemple d’une todolist (yet another one!) développée en React. Souvent en tant que développeur React, nous commençons par une phase de découpage des composants, Adrien n’y coupe pas (pun intended) et c’est intéressant de voir comment il fait avec la todo list. Dans un second temps, il nous a expliqué pourquoi faire le choix d’utiliser Storybook. Pour illustrer ses arguments, il nous a montré les inconvénients qui existent lorsqu’on développe sans Storybook : devoir tester manuellement son composant directement dans le browser, être forcé de changer les props à la main pour tester les variants, la difficulté d’avoir un bon jeu de données, l’absence de documentation, etc.

À l’issue de sa présentation, on réalise tout ce que peut apporter Storybook dans un projet : 

Dans le cadre de son projet IMPACT (Initiative for Minoritized Pioneers and Achievements in Computer Technology), Laura Durieux s’est lancée dans la conception d'une API, avec API Platform bien entendu, permettant à chacun de soumettre des informations à propos de personnes ayant révolutionné la tech. Cette API exposera un endpoint générant des pages descriptives à l'aide de l'IA.

Au-delà de l'aspect technique, démontrant les possibilités d'intégration dans API Platform, Laura a sensibilisé le public sur les différents types d'Intelligence Artificielle, et ce que cela implique, tant au niveau éthique, qu'économique ou écologique.

Łukasz Chruściel, co-fondateur de Commerce Weavers et Core Team Lead chez Sylius, nous a présenté à travers cette conférence les challenges auxquels a été confrontée son équipe pour migrer le fonctionnement interne de Sylius d’API Platform 2 vers API Platform 3. Sans surprise, ce fut un travail de longue haleine pour réussir cette montée de version : 752 commits, 1712 fichiers modifiés (+ 32,707 lignes et - 31,500 lignes) ! En effet, Łukasz a expliqué que Sylius comporte 73 endpoints pour la partie shop, 188 endpoints pour la partie admin, ce qui représente une codebase de presque 41 000 lignes réparties dans 562 fichiers.

Les principaux problèmes rencontrés ont été : la nouvelle classe pour les metadata, la nouvelle référence de configuration, la nouvelle architecture pour les providers et les processors et la nouvelle architecture des subresources. Rétrospectivement, Łukasz et la team Sylius admettent que cet effort a au passage permis d’implémenter un meilleur design, que leurs commandes sont d'avantages immuables, que Sylius est désormais davantage découplé du framework et que leurs tests les ont énormément aidé à réaliser cette montée de version. Pour finir, il nous a listé les éléments clés de cette migration, à savoir les tests, les commandes et leurs systèmes d’opérations, et a insisté sur l’importance de ces éléments qui ont rendu cette migration beaucoup plus sereine et moins coûteuse en efforts.

JustSteveKing AKA Steve McDougall, figure emblématique de Laravel, est DevRel chez Treblle. Le Gallois nous a montré toutes les étapes nécessaires pour obtenir une route d'API sécurisée sur laquelle les données sont récupérées, validées et stockées, le tout en utilisant uniquement Laravel.

Après quoi, il a remplacé l'entièreté de son code par une seule ligne de configuration API Platform, et il ainsi pu lister toutes les fonctionnalités que sa nouvelle API fournit en plus de ce qu'il avait mis en place lui-même lors des slides précédentes. Il est convaincu, que l'arrivée de API Platform dans Laravel va drastiquement améliorer la qualité des API développées avec ce framework, la rapidité de leur mise en place, et faciliter la vie des développeurs. 

L'intégration Laravel laisse plus de place pour se concentrer sur les fonctionnalités métier, tout en s'intégrant dans le quotidien des développeurs Laravel.

Sylvain Combraque est un développeur web freelance spécialisé dans le langage Go, contributeur actif au serveur web Caddy, à Træfik ou encore à API Platform. Sylvain a commencé par décrire le cache comme n'étant pas un concept informatique abstrait, mais simplement comme une mémoire que l'on peut consulter au besoin. Il a ensuite rappelé qu’avant la version 3.1 d’API Platform, Varnish était le seul système de cache implémenté dans le framework ; à l’époque, il n’y avait que deux "briques" à maintenir : Varnish et le serveur web.

Sylvain a poursuivi en abordant deux modules Caddy en particulier : Souin et cache-handler. Puis en présentant la définition et la description de RFC relatives au cache HTTP (cf. Mark Nottingham, le créateur de 38 RFC publiées), avant d’évoquer la description des CDN et les targeted cache-control (qui permettent d'être plus ou moins granulaires selon les cas d'usage).

Sylvain a ensuite abordé plusieurs RFC très récentes, pas encore publiées, mais très intéressantes : HTTP cache invalidation API et HTTP cache-groups. Il a continué son exposé en parlant de plusieurs thèmes liés au cache handler (les tags ESI, les storages supportés, - le request coalescing, etc.). Il a conclu sa présentation par une démonstration d'utilisation du cache dans une application API Platform utilisant FrankenPHP. 

L'API Platform Conference fut un immense succès, que ce soit en termes d’affluence, de nombre de partenaires, ou de diversité de speakers ou de sujets abordés. Depuis la clôture de l’édition, nous ne faisons que lire avec plaisir les avis dithyrambiques que nous réceptionnons aussi bien sur nos réseaux sociaux qu'à travers les comptes-rendus de nos partenaires (hello Codéin et Akawaka). Cerise sur le gâteau, au moment où nous écrivons ces lignes, nous venons de recevoir l’aftermovie de l’évènement, réalisé par Marie D'Angelo. Encore merci, Marie, pour ce travail fabuleux qui résume à la perfection l’atmosphère ambiante de cet évènement !

L'API Platform Conference reviendra le 18 et 19 septembre 2025 à Lille et en ligne pour une édition spéciale : API Platform fêtera ses 10 ans en 2025, une édition sous le signe des célébrations. Un autre article au sujet de l'API Platform Conference 2024 arrivera sous peu et vous détaillera les coulisses de l’organisation de cet évènement. D’ici là, encore un peu de patience pour découvrir les enregistrements des conférences, nous les partagerons sur notre chaîne YouTube et sur notre blog cet hiver.