La parole est aux speakers : Kévin Dunglas

Publié le

Jusqu’au Forum PHP 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

L’architecture ESA : le futur des API web

Cela fait déjà plus de 10 ans que je recherche les meilleures approches possibles pour concevoir des API web, que j’étudie méticuleusement les différents styles architecturaux existants et émergeants, et que je teste la quasi totalité des outils dédiés aux API web.

Fort de l’expérience acquise en développant de nombreuses API web “à la main”, j’ai décidé de créer un framework dont but est de simplifier cette tâche et de faire en sorte que les API qui l’utilisent respectent automatiquement les meilleures pratiques du domaine. Ce projet démarré pendant l’hiver 2014 est devenu le framework API Platform, l’un des outils les plus populaires pour créer des API. Un outil reconnu par l’ensemble de l’industrie comme l’un des plus simple à utiliser et en même temps comme l’un des plus avancés, si ce n’est le plus avancé, en matière de respect des standards (HATEOAS, RDF, Hydra, GraphQL…) comme des bonnes pratiques.

Le développement d’API Platform m’a permis de découvrir un nombre de cas d’usage toujours plus important et d’étudier de nouvelles pistes pour améliorer la performance, la fiabilité, la sécurité et l’évolutivité des API web.

Et bien entendu, grâce aux retours, challenges et suggestions de la communauté, de nouvelles idées me sont venues. Parmi elles, la possibilité d’utiliser HTTP pour permettre aux clients de s’abonner aux changements effectués sur les resources et de les recevoir en temps réel. C’est devenu le protocole Mercure. Plus tard, celle d’utiliser les nouvelles capacités des protocoles HTTP/2 et HTTP/3 (et en particulier le multiplexing) couplé à la possibilité de permettre au client d’indiquer au serveur de quelles données il aura besoin, afin d’améliorer la performance des API web et de permettre une mise en cache bien meilleure qu’avec les approches traditionnelles. C’est le protocole Vulcain.

Aujourd’hui, je souhaite vous proposer une nouvelle architecture pour les API web, basée sur ces années de travail de R&D ainsi que sur l’état de l’art de l’écosystème frontend (et oui !). Cette proposition, c’est l’architecture ESA.

ESA est une architecture novatrice, rompant avec les approches traditionnelles, qui permet de créer des API plus fiables, plus performantes et moins consommatrices en resources. Cette architecture renoue avec les grands principes REST/HATEOAS tout en tirant partie au maximum des nouvelles capacités fournies par la plateforme web. ESA promeut une approche mixte, mêlant synchrone et asynchrone, qui permet à la fois une très grande simplicité de développement et d’utilisation, des performances rarement atteintes, et la possibilité pour les clients d’avoir toujours des données à jour par rapport à celles dont dispose l’API. Finalement, ESA propose de s’appuyer sur les standards existants pour exposer une documentation “in-band” permettant la création de clients génériques, capables de découvrir les capacités de l’API au runtime.

Venez découvrir ESA, l’architecture qui va changer vos API web !

Katherine Johnson / Roissy
22/10/2021
10:15-10:55

La société que tu as co-fondée, Les-Tilleuls.coop, fête cette année ses 10 ans. Que retiens-tu de ce parcours de création d’entreprise ?

Tout a commencé à 3 sous les tilleuls de la terrasse d’un bar de Wazemmes. Aujourd’hui nous sommes 55 dans 4 villes différentes, nous gérons démocratiquement notre outil de travail et nous partageons équitablement les bénéfices produits. J’en retiens que la bière du Nord est miraculeuse et que – même dans la tech – on peut trouver des modèles alternatifs au venture capitalism, qui sont plus vertueux et donnent plus de sens au travail.

Nous avons parlé lors d’une dernière interview de Mercure et du processus de release d’une RFC, peux-tu nous faire une petite mise à jour sur ce qui s’est passé depuis ?

Mercure a maintenant été discuté sur les listes de l’IETF, ce qui m’a permis de découvrir d’autres projets tentant de répondre différemment à des problématiques similaires (en particulier Braid), d’échanger avec leurs créateurs et de faire évoluer le protocole pour couvrir des cas d’usages plus spécifiques.

Le protocole est maintenant très mature et utilisé par de nombreux projets en production.

Je suis en train d’effectuer les dernières retouches à la spécification suite aux retours des utilisateurs et utilisatrices ayant les cas d’usages les plus pointus (https://github.com/dunglas/mercure/pull/562). Quand ça sera fait, je proposerai au comité de l’IETF de publier le protocole, d’abord sous la forme d’un RFC indépendant (https://www.rfc-editor.org/about/independent/).

Tu es à l’origine du projet vaccin.click : une extension open source pour navigateur afin de réserver automatiquement des créneaux de vaccination. Peux-tu revenir sur la création de ce projet ? Celui-ci a-t-il été différent des autres projets open source que tu as créés ?

Quand la vaccination a été ouverte à tous, ma compagne et moi avons voulu nous faire vacciner. Sauf que nous nous sommes vite rendu compte que c’était quasiment impossible sans passer nos journées à rafraîchir Doctolib. Comme je n’aime pas perdre mon temps à cause d’outils informatiques mal pensés et que j’ai tendance à automatiser tout ce qui peut l’être, je me suis lancé dans l’écriture d’un petit script pour surveiller la disponibilité de créneaux à notre place (et plus efficacement que ViteMaDose, qui avait un temps de latence beaucoup trop important pour pouvoir obtenir un rendez-vous dans les grandes villes).

J’ai d’abord pensé utiliser notre langage préféré avec Panther, puis je me suis dit qu’une extension pour Firefox serait une meilleure idée. Déjà car ça faisait un moment que je voulais apprendre à en faire (j’ai quelques autres idées d’addons en tête) et que c’était l’occasion d’allier l’utile à l’agréable. Ensuite parce que j’avais pas mal de connaissances qui galéraient aussi à bloquer un créneau et qu’installer PHP puis configurer une tâche Cron n’est pas très adapté aux humains normaux.

Développer une extension s’est révélé plus simple que je l’avais pensé. En quelques heures c’était réglé. Une fois mon rendez-vous réservé, je l’ai publiée sur GitHub et sur Firefox Addons, et… il s’avère que beaucoup de gens cherchaient à se faire vacciner !

La différence principale que j’ai constatée avec les autres projets libres que j’ai pu publier, c’est les utilisateurs finaux. Distribuer un logiciel auprès d’un public non technique demande un peu plus d’attention en matière d’UI et de documentation. Des choses qui nous paraissent évidentes en tant que devs (par exemple qu’une extension pour navigateurs n’est pas une app mobile, ou qu’un logiciel s’arrête quand l’ordinateur sur lequel il est installé est éteint), ne le sont pas pour tout le monde. L’extension a permis à beaucoup de monde de se faire vacciner vite, les retours ont été très positifs, quelques autres devs ont ajouté des fonctionnalités et corrigé des bugs (un grand merci à eux !), et ça a fait parler de Firefox et du logiciel libre dans la presse grand public, donc c’était plutôt une réussite.

Une conférence présentée par

Kévin DUNGLAS
Kévin DUNGLAS
Kévin est le créateur du framework API Platform ainsi que des projets Mercure et Vulcain. Il est également membre de la Core Team Symfony et a cofondé la société autogérée Les-Tilleuls.coop.

Autres interviews