Notre retour sur les APIDays Paris 2018
Nous étions pour la première fois aux APIDays Paris mardi et mercredi dernier. APIDays est un cycle de conférence itinérant dédié à l’écosystème des APIs. À l’image des conférences Velocity, nous retrouvons les conférences dans le monde entier (San Francisco, Melbourne, Londres, …).
En France, c’est LA plus grosse conférence dédiée aux APIs. Cette année, plus de 2500 visiteurs étaient présents et cela s’est ressenti au niveau de l’accueil, l’espace partenaire étant assez immense !
Les acteurs majeurs qui font du business autour des APIs étaient présents. Nous avons donc retrouvé les solutions d’API Gateway (Tyk ou Kong), les entreprises qui développent des solutions d’API (Les Tilleuls avec API Platform, APIgee), les outils pour faciliter la vie des développeurs (Postman), des hébergeurs (Clever Cloud, platform.sh), bref beaucoup beaucoup de monde.
La particularité de cette conférence (bien qu’elle soit organisée en France) est de ne proposer que des conférences en langue anglaise. Nous sommes partagés sur l’intérêt. Certes, cela permet d’attirer du monde à l’international mais l’accent de certains speakers est parfois horrible pour nos délicates oreilles. Nous pouvons également regretter que cela ne rende pas accessible certains contenus à des personnes qui ne maîtrisent pas la langue anglaise (dans nos métiers, c’est un prérequis, mais ce n’est malheureusement pas maîtrisé par tous). Toutes les conférences sont donc en anglais, mais la plupart des échanges entre visiteurs se fait en langue française. Amusant…
Retour sur quelques thématiques de cette édition :
Section intitulée gestion-des-microservicesGestion des microservices
Souvent l’implémentation d’APIs en entreprise s’intègrent dans une démarche de développement en « microservice ». De nombreuses conférences avaient pour sujet la gestion de ces microservices et les mécanismes de reprise d’activité en cas de crash d’un des microservices. Phil Sturgeon, qui édite notamment APIs You Won’t Hate, a proposé une conférence très intéressante sur la gestion des dépendances entre les différents microservices. Il a notamment rappelé l’importance de définir des timeouts assez faibles. Cet article d’Octo résume bien les problématiques évoquées. Il a proposé des solutions permettant de mieux gérer les problématiques de dépendances :
- Circuit Breaker
Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l’échec.
Pour cela, en fonction d’un certain nombre de critères d’erreur (timeout, nombre d’erreurs, élément dans la réponse), ce pattern permet de désactiver l’envoi de requêtes au service appelé et de renvoyer plus rapidement une réponse alternative de repli (fallback), aussi appelé graceful degradation.
- Service Mesh
Le sevice mesh désigne une plateforme chargée d’assurer la sécurité, le routage et la tracabilité des communications entre applications microservices déployées de façon dynamique dans des contenus.
Les outils qui semblent sortir du lot sont istio et envoyproxy.
Un autre aspect des dépendances entre microservice est la problématique des sauvegardes. Dans le cas de dépendance entre des microservices, il sera souvent impossible (sans compromettre l’intégrité des données) d’effectuer une sauvegarde de l’ensemble des microservices.
Cesare Pautasso lors de sa présentation nous a notamment présenté le BAC Theorem :
« BAC theorem: when Backing up a microservice architecture, it is not possible to have both Consistency and Availability »
Section intitulée api-gatewayAPI Gateway
Les offres commerciales d’API Gateway étaient bien représentées (Tyk et Kong en tête). Nous avons participé au workshop de la solution Tyk. Pour avoir développé ce genre d’outils (API Gateway basée sur OpenResty, developer portal en Symfony/React) pour un client final, nous connaissons une partie des problématiques liés à ce genre d’outils. Les solutions commerciales semblent alléchantes mais le mode de facturation est souvent un frein à son intégration. Le workshop est resté trop général sur les fonctionnalités d’une API Gateway. Nous sommes restés sur notre faim.
Section intitulée graphqlGraphQL
Un track complet était bien entendu dédié à GraphQL. Nous avons particulièrement apprécié la conférence de Nick Van Wiggeren de Github. Il nous a présenté l’évolution des APIs chez Github et pourquoi ils avaient choisi GraphQL pour développer la V4 de leur API (argumentaire classique : réduction de la taille des réponses, documentation, …). Saviez-vous que lorsque vous interrogez certains endpoints de l’API v3 (REST) de Github, cela interrogeait en réalité l’API GraphQL ?
Nous avons particulièrement apprécié qu’il cite GraphQL doctor, outil développé par nos copains de Cap Collectif, permettant de prévenir les erreurs dans le schéma GraphQL directement dans les Pull-Requests Github.
Section intitulée outils-autour-de-openapiOutils autour de OpenAPI
La communauté autour de OpenAPI (ex-swagger) était également bien représentée. Des tracks complets étaient dédiés à l’évolution de OpenAPI. Nous n’y avons malheureusement pas participé.
De nombreux produits se développent autour de la spécification (générateurs de code, validateurs, …).
Pour faciliter l’utilisation de votre API, Avital Tzubeli de Kaltura nous a rappelé que c’est une bonne chose de mettre à disposition un client (SDK) généré à partir de votre spécification OpenAPI. Celui-ci sera toujours à jour et cela pourra peut-être permettre à vos partenaires de toujours utiliser la dernière version de l’API.
Chez JoliCode, nous maintenons d’ailleurs un outil permettant de générer un SDK (PHP) à partir d’une spécification OpenAPI. N’hésitez pas à aller y jeter un oeil : Jane.
Section intitulée devopsDevops
Un track complet était dédié à la culture DevOps. Nous avons apprécié la conférence de Christophe Rochefolle de oui.sncf sur le Chaos Engeneering. Il a rappelé que des groupes (Meetup ou Medium) se montaient sur cette thématique et qu’il ne fallait pas hésiter à les rejoindre.
Section intitulée evolution-des-apis-chez-arteEvolution des APIs chez Arte
Nous travaillons depuis plusieurs années avec ARTE sur l’évolution des APIs (mise en place d’une API Gateway, portail developpeur, maintenance de plusieurs APIs). Matthieu Breen a présenté l’évolution des APIs chez ARTE (d’API non authentifié, difficilement documentable) à une stratégie orientée autour des APIs.
Vous pouvez retrouver ses slides sur Speakerdeck.
Section intitulée l-ethique-des-developpeursL’éthique des développeurs
Stéphane Bortzmeyer, que nous ne présentons plus, a fait une conférence sur l’éthique et les droits humains. Sa conférence était une variation de celle qu’il avait déjà donné à Paris Web. Il nous a rappelé qu’en tant de développeurs/intervenants dans la technique, nous avons une responsabilité dans les choix techniques (ne stocker que les informations nécessaires, utilisation de services respectueux, …).
Il a évoqué le livre « CyberStructure » qu’il a écrit sur le sujet.
Section intitulée pour-conclurePour conclure
APIDays Paris 2018 était une très belle conférence, qui nous a donné l’occasion de croiser de nombreux acteurs gravitant autour des APIs.
Nous avons néanmoins regretté quelques petits soucis d’organisation (pas de temps de battement entre les conférences, micro HF non fonctionnel, petites salles, repas du midi pas assez fourni, …). Certaines conférences n’étaient pas au niveau attendu. Le processus de sélection pourrait peut-être être amélioré afin de limiter le nombre de conférences.
Néanmoins, nous reconnaissons l’énorme travail accompli. Bravo à toute l’équipe et à très bientôt.
Merci aux relecteurs non-JoliCodeurs (Matthieu, Ludovic, …).
Cet article porte sur la conférence ApiDays 2018.
