Vers la création d'APIs agnostiques

La tendance moderne du développement web est de séparer les vues et la logique d'application dans deux environnements complètement indépendants.

Cette tendance a été propulsée par React ou encore Vue.js, permettant de développer des applications Javascript, qui communiquent avec des services distants.

Architecture classique utilisée dans les CMS Headless, par exemple.

Chez Octree nous avons l'habitude de développer des applications suivant cette méthode. Cela nous a amené à réfléchir sur un autre workflow, tout aussi courant : celui de ne développer que les services et APIs sans connaître les détails de l'UI ni sur quels supports les applications vont être implémentées.

Développer des APIs agnostiques nous permettrait d’ajouter des fonctionnalités existantes à des projets sans pour autant modifier ce qui à déjà été fait. De plus, cela permettrait la création de synergies avec d’autres prestataires qui implémenteraient l’UI de nos services.

Dans le cadre de développement d’application, le développement de services donne la liberté de travailler à plusieurs équipes indépendantes ensemble et d'offrir, en cas de passage de projet, des transitions élégantes entre les prestataires.

Comme toutes les nouvelles idées chez Octree, nous commençons par implémenter un proof-of-concept (POC) afin de présenter à l'équipe l'idée et d'identifier les risques par le biais d'un petit projet.

Le problème : comment développer un service sans connaître ses futures implémentations UI

Formulation du POC

Ayant déjà travaillé avec des CMS Headless par le passé, nous avions une crainte concernant l'authentification. En effet, si la connexion doit se faire sur une application mobile et une application web en même temps, l'infrastructure nécessaire pour gérer la sécurité pourrait s'avérer complexe. De plus, si l'on reste dans un système de sessions, les implémentations permettant l'offline-first pourraient être compromises.

La deuxième crainte qui est ressortie de nos discussions est la création d'un service suffisamment flexible pour que le développement des applications ne soit pas freiné par nos APIs. Le besoin de fournir une API qui puisse être modifiée rapidement nous semblait être le deuxième point clé de ce POC.

Finalement, il nous semble que la documentation est aussi un des points sensibles, car elle doit être suffisamment explicite pour permettre aux développeurs de prendre en main notre service, tout en restant à jour. Ceci peut être un gros problème, surtout si les APIs sont vouées à changer rapidement – lors d'une version alpha par exemple, où des breaking-changes peuvent apparaître au fil des versions.

POC API-Only

Après quelques discussions autour du sujet, nous avons mis en place une expérience afin de tester nos plus grandes peurs.

En tant qu'administrateur, je peux me connecter à mon espace d'administration.En tant qu'administrateur, je dois pouvoir gérer des accès à des membres.En tant que membre, je peux me connecter à mon espace membre.En tant que membre, je peux voir l'ensemble des membres. En tant que membre, je peux éditer mes informations.

Ce POC nous permet de tester la gestion des sessions, la récupération et l'édition de données. L'exemple semble trivial, cependant ces deux services devront permettre la connexion d'un grand nombre de types d'applications. Nous avons choisi pour cela d'utiliser :

• Ruby on Rails avec Postgres

• de l'authentification OAuth2.0 et des Json-Web-Token

• du GraphQL et une interface GraphiQL

L'authentification et le GraphQL/GraphiQL feront l'objet de deux autres articles à venir. L'aspect concernant la documentation va être partiellement traité, mais un deuxième POC va peut-être s'avérer nécessaire si nous jugeons ce support de documentation insuffisant.

Conclusion

Prendre du recul pour considérer quel serait le proof-of-concept essentiel pour tester une nouvelle approche n'est pas quelque chose d'aisé. Le test n'étant pas encore sur un projet pilote, nous allons rater certains points critiques du workflow, car nous sommes ici très éloignés d'une application complexe.

Heureusement, nos expériences passées à créer des API's conjointement à des applications nous ont permis d'apprendre à rester attentifs à ces aspects.