L'artisan développeur

Blog de Sébastien Cormier
A la Une Conférences Général

API DAYS – Paris 2018

Le 30 et 31 janvier dernier avait lieu les API Days à la Cité Internationale Universitaire près du parc Montsouris. Ayant pu assister à la première journée, je vous livre ici mon avis sur les conférences auxquelles j’ai assisté. Sachez que malheureusement je n’y ai pu assister que la première journée.

Sustainable software: lessons from open source

  • Speaker : Arnaud Porterie (VP Engineering chez Vente-Privée)

Arnaud Porterie nous délivre une bonne présentation en guise d’introduction de l’API Days. Ce talk était particulièrement intéressant pour tous ceux qui cherchent de bons conseils pour gérer un projet Open Source.

Les points clés :

  • Importance de bien définir le scope pour les projets Open Source
  • Ne faire qu’une chose mais le faire bien !
  • Ne pas avoir peur de dire non.

 

Plus le projet grandit, plus il est nécessaire d’encourager les PR dans le projet. Dans une société:

  • L’inner source avec du vieux code, c’est toujours compliqué à maintenir. Il est nécessaire d’avoir plusieurs développeurs qui connaissent bien le code legacy, mais surtout, ne pas avoir d’équipes dédiées à çà.

 

Api is not just rest

  • Speaker : Kin Lane (API evangelist)

Ce talk a été assez décevant. Kin Lane a donné l’impression d’avoir la flemme de faire cette présentation. Les slides n’étaient pas vraiment travaillés. Le message passé consistait à expliquer que les API ne sont pas forcement en REST. Kin Lane a cité une liste de technologies qu’on peut utiliser aujourd’hui pour faire des API, à savoir :

  • Soap , XML rpc : on les utilise encore
  • Negotiate content layer. CSV, XML, json,…
  • Webhooks (pour faire du ‘push’ et non du ‘pulling’)
  • Websub (souscription à des événements en temps réél)
  • Server Sent Events SSE
  • Websockets
  • GRPC
  • Kafka (high performance streams, for internal operations. Not external API, only internal usage recommended)
  • MQTT ( Message Queuing Telemetry Transport )

 

Quelques points relevés :

  • Faire attention aux Headers, afin de permettre une meilleure compréhension de chaque API.
  • Contenu standardisé (JSON schema) : seulement si vraiment utile
  • Le client a toujours raison : Ecouter le besoin, ne pas pousser la techno préféré sans raison particulière.

 

Resilient microsercices webapi with rest and API gateway

  • Speaker : Vicenzo Chianese (LunchBadger)

Bonne performance de Vicenzo qui explique quelques astuces pour rendre une architecture micro-service robuste. Il explique aussi comment ne pas avoir à changer du vieux code en raison des effets collatéraux de l’évolution de l’architecture ou des autres services.

Un conseil : Faire d’abord un monolith, et penser micro-service plus tard. Quand le projet grossit, il faut découper.

Vicenzo nous a ensuite parlé de 2 problèmes récurrents :

  • Duplication du code dans des services distincts (authentication, security, logging, ….)
  • Propagation de l’implementation coté serveur chez le client : si quelque chose change sur le serveur, il est nécessaire de faire aussi le changement côté client.

Concernant le premier problème, il faut envisager d’utiliser une API Gateway en charge de tous les processus communs aux micro-services, puis de les dispatcher aux différents services.

Concernant le deuxième, toutes les réponses de l’API doivent retourner l’URL du service que le client aura besoin pour les prochains appels. Ainsi, si le ‘path’ ou le DNS change, le client ne sera pas impacté.

 

Graph API strategy

  • Speaker : Gareth jones (API architect Microsoft)

Très belle présentation de Gareth Jones pour introduire les API en mode Graph.

  • API economy key: self service. The biggest advantage is that you dont depend on others
  • 3 Graph API approaches: Graphql, odata, jsonapi.org
  • Cqrs, command and query responsibility segregation, was introduced too. A model for separating the read operations from the update ones. Useful for Graph API because multiple things can be done in one single call, comparing to simple REST ones.

 

Les micro-services avec GraphQL

  • Speaker : Martjin Walraven (Meteor / Apollo)

De mon point de vue, c’est la meilleure présentation à laquelle j’ai assisté aux API Days. Cela m’a donné envie de faire du GraphQL.

Les points clés du talk : 

  • GraphQL a été créé par Facebook
  • Les API Restful fournissent trop d’information donc la majorité est inutile. Comme un appel Rest est standard pour tout les clients, on doit retourner toutes les valeurs même si le client n’en a pas besoin.
  • Nous sommes la plupart du temps obligé de faire beaucoup trop d’appel (exemple : un appel pour les informations utilisateurs, un autre pour les commentaires et encore un pour ses contacts)

Le grand intérêt de GraphQL est que le client décide des informations à récupérer.

La deuxième partie du talk concernait GraphQL appliqués aux micro-services. Voici les principaux points :

  • Utiliser une API gateway est une bonne idée
  • Une API gateway avec GraphQL est la transition entre le front-end et le back-end
  • La connection entre le client et l’API Gateway se fait en GraphQL, puis l’API Gatesway dispatch les appels aux bons micro-services avec des appels Rest classiques.
  • « Apollo cache control » pour graphql a été présenté (un peu de publicité au passage…)
  • Il ne faut pas versioner ses services GraphQL. La solution est d’utiliser des champs dépréciés et de nouveaux champs.

 

API security

  • Speaker : Daniel sabin (OCTO Technologies)

Ce talk est un retour d’expérience des projets qu’il a vu chez Octo. Les points suivants ont été cités:

  • Technologies utilisés pour la sécurité: OAuth, owasp, API secure
  • Architecture constraints, identities, web security paranoia,
  • Vieux protocoles de sécurité utilisés : OAuth 2.0 (pour la délégation, pas pour l’authentification ou la gestion des droits) et OpenID (gestion des droits)
  • L’utilisateur ne s’authentifie jamais chez le client
  • Problème : le client ne sait pas qui il est
  • Les contraintes de sécurité sont déportés chez le client
  • Oauth possède plusieurs extensions, ex: to add sessions

 

Secrets behind restful, API project specs

  • Speakers : Julie Rollin & Hugo Hache (FABERNOVEL TECHNOLOGIES)

Pour terminer, j’ai assisté à un dernier retour d’expérience d’un Tech Lead et de son Product Owner. Les points que j’ai retenu sont :

  • Les « crashs » d’une API proviennent toujours d’une mauvaise spécification
  • Ils considèrent que les outils pour API ne sont pas synchro : postman, swagger, ….
  • Du coup, ils ont mis en place une solution maison pour tout synchroniser
  • C’est une solution utilisant Json Schema, qui permet de faciliter le design d’API et de bouchonner : Pericles (https://github.com/applidium/pericles)

 

 

 

Conclusions

C’était ma première participation aux API Days, et franchement j’avoue que j’y allais un peu à contre-coeur, j’étais un peu mitigé. Mais au fur et à mesure que la journée avançait, je me rendais compte que le niveau des participants était loin d’être amateur, et que presque tous les talks abordaient de vraies problématiques back-end.

Le seul point que je critiquerais, c’est la durée des présentation, trop courte à mon goût. De ce fait, si la présentation n’est pas complètement adaptée, soit on a l’impression que le sujet est trop survolé (et que l’on veut en savoir plus), soit qu’on a du assimiler trop d’infos.

Mais au global, comme j’ai déjà dit, à refaire!!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.