Retour sur l'API Platform Conference 2024 - jour 1

Après des mois de préparation, de teasings quotidiens, des centaines de mails, de la vitamine C et des dizaines de milliers de pas effectués par jour, l'API Platform Conference s'est déroulée avec succès les 19 et 20 septembre derniers. À l'heure où nous écrivons ces lignes, nous continuons de lire avec plaisir les nombreux retours et articles de nos participants, tous unanimes sur la qualité des conférences et l'atmosphère conviviale vécue sur place à EuraTechnologies. Maintenant que nous nous tournons vers l'édition 2025 prévue les 18 et 19 septembre prochains, et en attendant la diffusion du replay (laissez-nous juste un peu de temps de montage), remémorons-nous les sujets abordés lors de cet événement où plus de 300 personnes ont participé.

La conférence a débuté en grande pompe avec l'annonce par notre co-gérant Kévin Dunglas des versions 3.4 et 4.0 d'API Platform !

Ces deux nouvelles versions, taguées pour l'occasion, modifient en profondeur la structure de ses modules, notamment pour apporter le support de Laravel, ce qui laisse entrevoir de nombreuses nouvelles perspectives techniques pour API Platform. Cette nouvelle approche va indubitablement faciliter les futures intégrations et encourager l’usage d’API Platform au sein d’autres outils et frameworks de l'écosystème PHP (Drupal, Ibexa DXP, etc.). En prime, API Platform voit arriver son lot d'améliorations, avec notamment son système de filtre, laissant penser que dans les prochaines itérations, nous allons enfin voir apparaître les filtres “OR” tant demandés par la communauté. 

Également annoncés, les futurs supports de Mercure 1.0, Laravel Broadcast et Lavarel Echo. Découvrez davantage de détails sur cette keynote dans les slides de Kévin, disponibles sur son blog.  

L'IA est véritablement une partie prenante de notre vie de développeur. Autant avec l’objectif de compléter des aspects métiers de nos projets, qu’avec celui de simplifier notre quotidien au sein de nos outils techniques. C'est ce dernier aspect que Matthieu Werner, consultant chez Tiime, a abordé durant sa conférence, à travers un tour d'horizon des intégrations de l'intelligence artificielle dans les IDE, les outils d'analyse statique, les outils d'analyse dynamique ou de surveillance, ou encore les outils de consommation d'API. Il devient ridicule de lister et citer un produit spécifique tant c'est devenu la norme pour tout produit d'intégrer une telle fonctionnalité.

Après le passage en revue de ces différents cas d’utilisation, Matthieu a évoqué les problématiques liées à l’IA en matière de droits et de consommation énergétique. Cette conférence était un bon état des lieux du marché de l'IA pour nos usages personnels, mais aussi une nécessaire introduction aux questions éthiques posées par l’IA.

Sergès Goma, développeuse chez Eveasoft, accompagnée de son rire communicatif, est venue questionner les devs présents en salle à propos de leur rôle et de la responsabilité politique qui lui incombe.

S’appuyant sur la roue des valeurs universelles (un concept introduit par Shalom Schwartz) pour nous faire comprendre qu’un intérêt viens toujours s’opposer à un autre,  nous donne des clés pour analyser et placer les intérêts de chacune des parties prenantes, mais aussi pour mesurer leur importance dans cette chaîne d’interdépendance. Par exemple, un utilisateur pourrait perdre en autonomie si les besoins de sécurité du commanditaire sont appliqués, à nous alors de déterminer la suite en fonction de notre système de valeur, notre environnement culturel et de ce que cela implique réellement par rapport à notre fonctionnalité : est-ce acceptable moralement ou seulement légalement ?

Une des solutions proposée avec humour (ou pas) pour trancher les dilemmes les plus épineux : “Quit your job” !

Lors de cette conférence, notre coopératrice Allison nous a présenté un cas d'usage autour d'un site de casino en ligne, visant à mettre en place un système de notification en temps réel permettant d'envoyer des alertes dès qu'une activité frauduleuse est détectée. Elle a commencé avec un rapide historique du protocole HTTP et de ses améliorations successives, depuis HTTP/1 et ses limites, jusqu’à HTTP/2 puis désormais HTTP/3. L’idée principale à retenir étant que le protocole est aujourd’hui bien mieux sécurisé, mais qu’il reste inadapté pour gérer nativement des notifications en temps réel. 

Elle a ensuite listé les différentes techniques permettant de faire du temps réel, ainsi que leurs avantages et inconvénients respectifs :

Allison a expliqué comment configurer des notifications en temps réel avec Mercure, en détaillant l'installation, la configuration, et l'outil de débogage. Elle a ensuite couvert les concepts clés comme les topics, les mises à jour statiques et dynamiques, ainsi que les types de mises à jour (restrictive et canonical).  Enfin, elle a montré comment traiter les messages avec Messenger et a présenté la fonction mercure() de Twig ainsi que les options de souscription aux autorisations. Vous découvrirez davantage de détails sur sa conférence quand nous diffuserons le replay !

Dans cette conférence, le co-fondateur de baksla.sh nous a présenté le nouveau composant JsonEncoder dont il est à l’origine et qui est voué à remplacer l'encodeur JSON de symfony/serializer. Il nous a détaillé ses deux principaux avantages :

Les gains de performances ont été rendus possibles grâce à la création de "templates" PHP générés lors du cache warm-up ou à la volée lors du premier appel. Ces templates sont construits grâce aux types des propriétés ainsi qu'à de nouveaux attributs, ils représentent la structure du fichier JSON qui sera généré. Cette connaissance préalable du JSON permet également l'encodage en stream, c'est-à-dire que l'intégralité des données n'ont pas besoin d'être chargées en mémoire pour être sérialisées. C’est particulièrement utile lors de la sérialisation d’une très grosse quantité de données, qui avec le sérialiseur actuel, devraient être chargées en mémoire entièrement, causant couramment des problèmes de ressources.

L'après-midi s'est ouvert avec la keynote d’Antoine Bluchet, le release manager d’API Platform et consultant au sein de notre coopérative. Suite aux annonces faites par Kévin Dunglas le matin même, Antoine ouvre son éditeur pour nous présenter un peu plus en détail la philosophie des nouvelles fonctionnalités du framework.

Pour s'ouvrir à Laravel et faciliter d'autres intégrations futures, le prix à payer est la dépréciation de quelques namespaces ainsi que des options pour assurer la rétrocompatibilité dans le fichier de configuration d’API Platform. Antoine nous a ensuite présenté les stateOptions, la notion de EdgeSideAPI, le système de QueryParameters, la nouvelle gestion des erreurs rendue plus flexible et bien d'autres nouveautés ! Petit point d'attention, dès la version 3.4 veillez bien à mettre l'option hydra_prefix à true le temps de mettre à jour vos clients, au risque de voir le préfixe disparaitre de vos réponses en 4.0.

Au final, cette seconde keynote nous a dévoilé l'énorme boulot réalisé ces derniers mois par la core team et surtout les deux années de travail préparatoire nécessaires pour arriver à ce résultat.

Trois ans après son premier passage à l'événement, François Zaninotto, le fondateur de Marmelab et créateur de ReactAdmin est venu présenter API Platform Admin. Il a commencé par comparer les différentes solutions existantes pour générer des interfaces d'administration : SonataAdminBundle, EasyAdminBundle et API Platform Admin. La dernière est d'après lui la plus simple à utiliser, tout en restant la plus facilement extensible lorsque les fonctionnalités de base ne sont pas suffisantes.

François a ensuite argumenté pour justifier sa préférence : 

Enfin, API Platform Admin se base sur des librairies populaires telles que React et Material Ui, ce qui donne accès à de très nombreuses fonctionnalités développées par la communauté, sans avoir (ou presque) à écrire de JavaScript !

Clément Talleu, développeur “homemade” tilleuls est quant à lui venu nous parler des attributs PHP. Depuis leur implémentation en 2020 leur présence est devenue incontournable que ce soit dans l’écosystème Symfony, qui y a énormément recours, mais aussi dans API Platform où la grande majorité des fonctionnalités sont disponibles directement grâce à quelques attributs et leurs nombreux paramètres.

Après un bref retour historique sur les différentes RFC qui ont mené à leur implémentation, nous avons ouvert le capot pour comprendre concrètement comment créer et utiliser des attributs puis comment ils sont mis en place dans Symfony et dans API Platform avec plusieurs cas d’usage.

Notre co-gérante et directrice technique a commencé sa conférence en rappelant pourquoi il est important de documenter son API : la documentation permet de spécifier notre API, c'est-à-dire d’expliquer ce qu’elle fait. API Platform permet de configurer finement la documentation générée automatiquement, mais peu de devs connaissent précisément les nombreuses options qui permettent de la personnaliser.

Marion a ensuite utilisé un parallèle entre le vélo et la génération de documentation. La génération de doc avec API Platform, c’est un peu l’équivalent du vélo à roulettes : par défaut, API Platform génère une documentation standard et nous pouvons nous concentrer sur notre code, notre POC, etc. Cependant, les roulettes du vélo peuvent parfois devenir gênantes, il est alors possible de les retirer pour personnaliser la documentation générée.

Elle a ensuite évoqué le format le plus connu : OpenAPI. Elle a aussi rappelé aux personnes présentes que, si API Platform peut générer la documentation à partir de nos endpoints, il est également possible de faire le contraire : commencer par écrire la documentation OpenAPI, pour ensuite générer les endpoints grâce à la commande `schema`. Elle a ensuite mentionné les deux UI les plus courantes : Swagger UI et ReDoc, toutes les deux disponibles dans API Platform.

Marion a conclu sa conférence en nous expliquant comment aller encore plus loin dans la configuration de la documentation, notamment en décorant la classe OpenApiFactory et en nous détaillant de nombreux cas d’usage (déprécier une opération, ajouter un endpoint custom, ajouter des informations, ajouter une liste de serveurs (pour la sandbox), ajouter des méthodes d’authentification, ajouter un modèle (JSON Schema), filtrer les ressources par permission, etc.).

Stefan Koopmanschap, cofondateur de Ingewikkeld, est revenu cette année pour nous proposer une introduction au Domain-Driven Development (DDD). Après avoir évoqué les différents ouvrages de référence (The blue book, The red book) et rappelé que ce design pattern est surtout adapté à des projets complexes, il nous l’a exposé avec un regard non-technique.

Il commencé par expliquer l’importance de définir un langage commun entre les personnes en charge du métier et les personnes chargées du développement. De cette façon, même une personne non technicienne pourra avoir une idée de ce que fait le code en le lisant. Stefan nous a ensuite brièvement parlé des différentes étapes de conception d'un projet DDD : event storming, aggregates, ….

Le message à retenir de cette conférence est qu'il est important de bien savoir ce sur quoi on travaille avant de commencer à coder.

Derick Rethans travaille à la PHP Foundation, il s'occupe notamment de la gestion des dates dans PHP, et est particulièrement connu pour être le créateur de Xdebug dont il assure la maintenance depuis 23 ans ! Dans sa conférence, il nous a présenté les dernières innovations de cet outil, qui facilitent grandement sa mise en place et son utilisation. Dans le désordre, Derick a ainsi présenté :

Pour conclure, Derick a évoqué une idée actuellement en cours de développement : pouvoir résoudre le code des templates compilés avec les breakpoints. Il a également fait mention de son service Xdebug Cloud, qui existe depuis maintenant trois ans, et qui facilite l’utilisation de Xdebug sans devoir gérer toutes les complexités liés au réseau.

Frédéric Bouchery est architecte et lead developer chez CCM Benchmark Group, où il gère des pipelines de transformation de données capables de traiter 2 milliards de données par jour.

Pour traiter cette immense quantité de données, il utilise RabbitMQ à grande échelle et a donc profité de sa conférence pour partager avec nous son expertise et introduire aux fondamentaux de RabbitMQ. Frédéric a présenté l’architecture de RabbitMQ, ses garanties, sa configuration avec Symfony… Pour illustrer ses propos, il nous a décrit le modèle utilisé dans son entreprise, composé de plusieurs éditeurs et de plusieurs consommateurs, profitant de l’occasion pour attirer notre attention sur le préchargement (prefetch) : par défaut, RabbitMQ permet aux consommateurs de récupérer plusieurs messages en une seule requête ; si le consommateur échoue à traiter les messages pour une raison quelconque, ces derniers sont renvoyés dans la file pour être traités par un autre consommateur. 

C’est pourquoi il ne faut pas présumer que le traitement s’effectuera toujours dans l’ordre de réception des messages, ou, le cas échéant, configurer RabbitMQ avec un préchargement défini à zéro afin de garantir que ce soit le cas.

Jeanne Londiche, ingénieure en recrutement spécialisée en PHP, Olivier Mansour, architecte chez Théodo et représentant de l'AFUP accompagné des chiffres du baromètre éponyme, et Clément Talleu, lead developer chez Les-Tilleuls.coop, ont échangé durant une quarantaine de minutes à propos de leur vision du marché de l'emploi en 2024. Le sujet étant tellement vaste, cette table ronde aurait pu sans problème durer plusieurs heures, mais voici les principaux sujets abordés :  

Vous le découvrirez lors de la diffusion du replay de cette conférence, prévue cet hiver !

Encore un peu de patience pour découvrir le compte-rendu du second jour. En attendant, découvrez les photos de l'événement (réalisées par Nicolas Detrez) sur notre page Flickr !