J’ai profité du début de mes vacances pour lancer un side project qui trainait dans mes cartons depuis quelques mois sans que je trouve le temps de m’y atteler. J’ai donc créé mes modèles, codé mes premiers contrôleurs, ajouté quelques vues… tout ça commençait à ressembler à quelque-chose. Puis l’heure de la sieste s’est achevée, et nous sommes partis nous baigner. Pendant la baignade, je me suis laissé aller à imaginer ce que deviendrait mon projet d’ici quelques mois. La roadmap était ambitieuse : tout d’abord, une version Web mobile, puis une application native pour l’iPhone, probablement pour iPad… Pour tout cela, il me faudrait rapidement développer une API à côté de l’application principale, d’autant que quelqu’un développerait certainement un client Android.

Stop. Rewind. Il me faudrait rapidement développer une API à côté de l’application principaleil me faudrait rapidement développer une API à côté de l’application principaleil me faudrait rapidement développer une API à côté de l’application principale. On arrête tout et on recommence.

Je suis rentré à la maison, j’ai remisé tout ce que j’avais fait dans un coin, et j’ai (presque) tout repris de zéro, afin d’articuler tout mon projet autour d’un backend fournissant une API, et de divers frontend manipulant les données renvoyées (en JSON) par ladite API.

Architecture autour d'une API

Implémentation

En ce qui concerne l’implémentation, je suis pour l’instant parti sur la Gem Rails::API, après m’être laissé convaincre par le Railscast qui lui est consacré. Elle correspond tout à fait à ce dont j’ai besoin.

Côté logique, tout ou presque se fait dans l’API. L’utilisation des utilisateurs se fait avec Oauth 2. Pour tout ce qui est workflow, j’utilise une state machine ; il y a certainement plus simple et plus efficace, mais j’ai déjà utilisé le système, donc j’évite d’avoir à réinventer ma roue.

Je travaille pour l’instant en parallèle sur l’API et la Web UI. Pour cette dernière, je suis parti sur une application Rails extrêmement simple principalement pour deux raisons.

  1. J’aurais certainement pu le faire en full HTML + JS en évitant d’utiliser une technologie serveur, mais l’API renvoie des données JSON brutes, et je voulais pouvoir gérer de ce côté tout ce qui est gestion des routes et l’affichage des erreurs.
  2. Je suis une grosse ouiche (lorraine) en JS, et je veux avancer rapidement sans avoir à tout réapprendre d’un langage qui me hérisse le poil, même si mon collège Laurent m’assure que ça a changé et que ça rox des poneys.

Inconvénients

Je vois quelques inconvénients à cette manière d’architecturer mon application autour d’une seule API.

Les premières sont d’ordre philosophique.

En faisant cela, j’ai brisé la règle du release early, release often, puisque j’ai tout refait de zéro avant même de savoir si mon projet vaut le coup / est utilisable, avec pour risque de ne jamais rien sortir. Classique, vous n’imaginez pas le nombre de next big thing inachevées qui trainent sur mon disque dur.

Même si je sais que cela va me faciliter la vie, je commets un design smell puisque je rajoute beaucoup de code qui me servira “plus tard”, “au cas où”. D’un autre côté, j’en ai besoin tout de suite, puisque sans l’API, ma Web UI ne peut pas fonctionner.

Le jour où je voudrai modifier l’API, je serai obligé de modifier l’intégralité des applications l’utilisant, et notamment la Web UI. Cela signifie probablement que je devrai faire tourner deux versions de l’API en parallèle, il faudra donc que l’évolution du modèle de données soit rétro compatible.

Avantages

Pour le reste, je ne vois que des avantages à architecturer mon application comme cela, même si le bootstrap se fait beaucoup plus lentement qu’avec une application Web traditionnelle.

Je ne courre aucun risque de divergences logiques ou fonctionnelles entre l’application Web et les applications tierces se basant sur l’API puisque tout le monde passe par le même code.

Pas de duplication de code entre l’application Web et l’API, comme cela arrive souvent quand on ajoute une API à un produit existant.

Plusieurs personnes peuvent développer les applications de mes rêves en parallèle pendant, et ce très très tôt, puisque la première version de l’API sera fournie dès la première version de l’application.

Quant à moi, je vous laisse, je vais retourner coder en attendant de faire refroidir mes coups de soleil.

Parapente