Architectures, technos et langages : les choix et leurs conséquences

En mission de coaching technique auprès d'une équipe pour les aider à choisir et mettre en place une nouvelle stack complète (back, front, micro-services, base de données, etc...), j'ai été amené à mettre en avant, auprès de cette équipe, les conséquences de nos choix. Je partage mon REX.

La théorie

En théorie, un principe de base et d'être capable de remplacer, dans l'architecture du produit, n'importe quelle brique à n'importe quel moment. On va donc choisir chaque brique de manière à ce qu'elle ait un lien le plus faible possible avec le reste de l'architecture. Comme cela, le jour où cette brique ne fait plus l'affaire, ou qu'on en découvre une meilleure, hop, on remplace ! Cool !

Et comme ce choix n'est pas toujours évident, un autre principe important est de repousser au maximum le moment du choix. Exemple : nous choisirons la base de donnée au moment où nous en aurons besoin. Re-cool !

Quelques constats

Sans détour, autant tout de suite avouer que pour moi, le 1er principe ci-dessus est rarement applicable. Il reste cependant intéressant, et il est donc important de l'avoir en tête, pour repousser la limite le plus loin possible.

Pour donner quelques exemples, il est illusoire d'imaginer :

• Remplacer sa base SQL par une base No-SQL 
• Changer le langage de son backend
• Remplacer son framework de Front par un autre, par exemple Angular par ReactJs
• etc...

Mon approche : réalisme & pragmatisme

J'essaie d'estimer les contraintes et les implications d'un choix selon 3 niveaux :

1. La brique pourra être facilement remplacée, à moindre cout, et sans trop d'impact sur le reste de l'architecture, du produit, des utilisateurs, et de l'équipe
2. La brique pourra ou pourrait être remplacée, avec un cout non négligeable, et peut-être des impacts sur le reste, donc à gérer
3. La brique ne pourra objectivement pas être remplacée, ou alors avec un cout très important (= ré-écriture d'une partie de l'application), probablement des impacts et risques sur le produit

Quelques exemples rencontrés récemment lors de mon coaching technique.

Backend : niveau 2

Choix : Spring boot et Java (potentiellement Kotlin par la suite)

Notre backend sera essentiellement là pour servir des données en REST, et échanger avec la base de donnée ou des micro-services. L'équipe est expérimentée en Java, peu de chance de partir sur un autre langage totalement différent (NodeJs, PHP, ...). Si nous devions remplacer cette brique, nous pourrions probablement récupérer une bonne partie du code Java, surtout s'il est bien découpée, avec une "incrustation" de Spring la plus limitée possible.

Front : niveau 3

Choix : ReactJs, Sass et ES6

Nous avons fait le choix d'une "RAI" ("Rich Application Interface"), qui n'est en passant pas forcément toujours "le" bon choix, et nous avons retenu ReactJs face à Angular ou VueJs. Il est illusoire de croire qu'on peut remplacer un framework Front facilement par un autre, et développer sa propre couche d'abstraction est une erreur ! Ici encore, il est très important de bien structurer son code JavaScript pour limiter au minimum le code fortement lié au framework. Le reste du code pourra être en grande partie repris, mais tout le code de rendu, lié au framework, devra être ré-écrit.

Concernant Sass, je ne me suis même pas posé la question, tellement son utilisation est une évidence, et tellement il n'y pas d'autres choix actuellement. Idem pour ES6 qui est une évidence, transpilé ou pas.

Base de donnée : niveau 2

Choix : repoussé

Pour l'instant, nous n'en avons pas besoin, donc le choix est repoussé. Néanmoins, ce choix sera impactant, de niveau 2 si nous restons dans la même famille (SQL par exemple).

Build du Front : niveau 1

Choix : Webpack

Builder le front consiste à transpiler le Sass, éventuellement le code ES6, optimiser les images, concaténer et réduire les sources CSS et JS, jouer les tests unitaires, regrouper le tout dans 1 ou quelques fichiers, etc... Ces opérations sont classiques. A ce jour, je ne suis pas un fan de WebPack, un peu trop "boite noire" a mon gout. Par contre, nous étions contraints par le temps, et c'était très rapide à mettre en place pour faire le job. Et décider un jour de ne plus utiliser Webpack a très peu d'impact sur ce que nous aurons produit, il faudra "juste" composer notre usinage plus manuellement et à notre gout.

Tests unitaires du Front : niveau 2

Choix : Jest et Cypher

Le choix de la techno pour les tests unitaires du Front, Javascript et éventuellement les composants, est assez déterminant notamment au niveau de la syntaxe d'écriture des tests, voire des mocks. Par exemple, une série de tests basés sur Mocha+Chai+Sinon nécessite une ré-écriture important, voir totale, pour passer à Jest.

Micro-service : niveau 1

Choix : repoussé

Tout comme la base de donnée, nous n'en avons pas encore besoin, donc le choix technique est repoussé. Quoi qu'il en soit, je le met au niveau 1 car l'idée même d'un micro-service est d'être petit, avec un rôle fonctionnel très précis et limité. Changer de techno pour un micro-service n'est pas un problème car il faudra ré-écrire le micro-service, et ce n'est pas un problème !

Conclusions

• Même s'il est en partie illusoire, gardez en tête le 1er principe qui permet de faire de meilleurs choix
• Repoussez les choix au maximum, attendez d'en avoir l'usage et donc une meilleure visibilité sur les contraintes et vos besoins réels
• Posez-vous la question du "ticket d'entrée" pour tel ou tel choix, quel cout pour l'équipe pour la mise en place et la montée en compétence
• Découpez correctement votre architecture à tous les niveaux : backend / front / micro-services, mais également au sein de votre code pour isoler les codes liés aux frameworks choisis, et ainsi limiter l'impact d'un éventuellement changement
• Pour les choix de niveaux 2 et 3, prenez le temps de bien estimer vos besoins et les réponses à ces besoins par telle ou telle solution, en imaginant ne plus jamais pouvoir en changer