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

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :