Lecture 6 minutes
Kévin Dunglas, auteur de API Platform mais également des protocoles Vulcain et Mercure, nous propose une conférence, lors du Forum PHP 2021, sur sa vision du futur des APIs web et où il souhaite aller avec les différents outils qu’il a développés.
REST
Il commence par nous rappeler les principes de l’architecture REST qui est à la base du style architectural du web lui-même, imaginé en même temps que le protocole HTTP.
Dans une architecture REST, on navigue entre les documents et les ressources via des liens, de la même manière qu’une page web html classique. Différentes spécifications existent pour implémenter ce style architectural telles que JSON-LD, hydra, HTTP, URI…
Ces spécifications sont celles implémentées par API Platform car ils font partie des standards définis par le W3C et IETF.
REST fête ses 21 ans, depuis le web a été amené à évoluer notamment avec HTTP/2 et HTTP/3. Kévin met l’accent sur l’une des grosses nouveautés qui est le multiplexing, permettant de télécharger des ressources en parallèle.
Cache
Une des caractéristiques importantes est la capacité de mise en cache par le protocole HTTP.
Le protocole nous offre des outils pour la gestion du cache, à l’aide de headers permettant de définir une date d’expiration ou le numéro de version d’une ressource. Malheureusement il n’y a pas de système d’invalidation standardisé, plusieurs protocoles sont en concurrence pour gérer ce cas de figure.
De nouvelles directives sont disponibles aujourd’hui pour gérer d’autres cas de figure. Kévin nous parle plus spécifiquement de stale-while-revalidate et stale-if-error, elles représentent un compromis entre expérience utilisateur et fraîcheur des données.
Stale-while-revalidate
Le navigateur va utiliser le document qu’il a en cache mais va quand même aller demander s'il y a une nouvelle version.
Stale-if-error
Le navigateur va préférer servir le document en cache plutôt qu’une erreur 500 par exemple.
Infrastructure
Une autre chose qui a changé en 20 ans c’est l’infrastructure. Outre la multiplication des câbles et serveurs reliant les différentes régions du monde, nous avons connu la démocratisation des CDN (Content Delivery Network) ainsi que du Edge Computing.
Un CDN est un serveur de cache HTTP distribué qui permet d’avoir des copies de documents partout dans le monde et améliorer la délivrabilité des données tout en réduisant la consommation nécessaire à leur acheminement.
Le edge computing permet de déployer du code qui sera exécuté au plus près de l’utilisateur. C’est la même chose qu’un CDN mais pour exécuter du code. Dans les plus connus, Kévin cite Vercel, AWS, Cloudflare…
Jamstack
L’écosystème frontend exploite déjà ces infrastructures, notamment par le biais de frameworks avancés tels que Next et Nuxt (surcouche de React et Vue) dans le cadre de l’architecture JamStack.
Dans ce style d’architecture, les outils vont pré-générer notre application web sous forme de fichiers statiques qui seront déployés sur des CDN. Ces applications bénéficieront de toute la puissance de nos infrastructures modernes pour être délivrées à un très grand nombre d’utilisateurs simultanés avec une latence minimale.
Plusieurs stratégies sont apparues au fil des itérations concernant l’étape de génération des fichiers de l’application.
SSG (Static Site Generation)
On génère toute l’application d’un coup et on déploie sur CDN.
ISR (Incremental Static Regeneration)
Génération d’une partie, et le reste à la demande via du edge computing. On peut coupler l’ISR avec le stale-while-revalidate, qui va nous permettre de servir le fichier pré-généré en cache tout en allant générer la nouvelle version plus à jour pour l’utilisateur suivant.
Edge Side APIs
Tout cela nous amène à l’architecture ESA imaginée par Kévin qui consiste à apporter les innovations du front-end (JAMstack et ISR) dans l’écosystème des APIs back-end.
L’idée serait de pré-générer des documents JSON statiques via du edge computing et de les servir à l’aide des CDN. Cela permettrait d’avoir nos endpoints API qui répondent même si les serveurs sont KO.
Ce style architectural embrasse les principes REST et peut être implémenté dans n’importe quel langage. Ce sera à la base de l’architecture d’API Platform 3.
Contraintes à respecter
Pre-generate
On génère le plus de réponses API possible à l’avance, on stock ça dans un CDN, on régénère les documents impactés par les changements (écritures) qui ont lieu après le déploiement.
Atomic Resources
On sert des documents atomiques, qui sont les plus petits possible. Il faudra éviter de faire des documents embarqués. (On n'embarque pas les documents enfants dans les parents). À la place on utilisera des liens et on respectera les principes REST. Pour avoir l’enfant il faudra naviguer entre les liens. Grâce au multiplexing on pourra en récupérer plusieurs à la fois.
Progressive
L’API doit être progressive, elle doit donc être capable de s’adapter à l’appareil client qui demande la donnée, doit fonctionner avec un vieux navigateur mais être capable d’utiliser les meilleurs outils intégrés dans nos navigateurs modernes.
Preload
Les navigateurs modernes supportent le preloading. C’est à dire qu’ils peuvent, à partir des headers, télécharger des documents avant que l’utilisateur en ait besoin.
Note : Le protocole Vulcain conçu par Kévin cible cette partie en particulier.
Push (optionnel)
Être en mesure d’informer les clients des nouvelles mises à jour (lors d’écriture, modifications dans les sources de données) pour qu’elles soient poussées instantanément aux utilisateurs. Pour cela on peut utiliser un autre protocole conçu par Kévin, Mercure.
Liste d’outils qui permettent d’implémenter une architecture ESA
En résumé, le modèle ESA est une architecture moderne pour nos API REST, exploitant les features de nos navigateurs et de nos infrastructures pour penser un web plus rapide, résilient, et moins consommateur.
Le sujet vous interesse ? (re)découvrez en vidéo la conférence de Kevin Dunglas
