Recoder une app web de zéro: le défi du produit Livementor
Lorsque je suis arrivé chez Livementor en tant que Développeur Front-End, ma première mission a été d’expertiser et de mettre à jour l’application web en proposant une solution viable et pérenne.
Ce qui m’a surpris, c’est d’abord l’architecture de l’app qui n’avait que très peu changé depuis sa création — en tant que freelance, j’étais plutôt habitué à travailler sur des projets “neufs”. Mais dans le cas de Livementor, qui existe depuis quelques années maintenant, l‘équipe était mobilisée sur d’autres chantiers plutôt que d’opérer une migration: c’était une bonne occasion pour redonner un bon coup de peinture!
Depuis 7 ans, l’app codée en Ruby, côté back-end, se chargeait de gérer la partie serveur (lourde et complexe, liée comme toutes les start-ups, à une problématique métier très précise — ici l’accompagnement des entrepreneurs, leur parcours au sein du programme Livementor ainsi que tout l’espace attribué à leur relation avec les mentors…). Mais elle se charge également de générer et de délivrer le front-end ! Une lourde charge qu’il fallait désormais, alléger.
Comment éclater le monolithe!
Comme beaucoup de start-ups actuellement, nous avons opté pour un changement d’architecture et une réorganisation complète de notre produit digital.
Mais c’est quoi un produit monolithique?
On va faire simple. Un monolithe, c’est ça:
D’accord, la forme vous évoque certainement autre chose mais cela reste un monolithe! Un bloc de pierre uniforme, impossible à déplacer, d’un seul tenant, qui se briserait dès la première chute. Jusqu’à présent, l’architecture de Livementor, c’est un monolithe — d’un seul tenant — c’est à dire ça:
Quel est le problème? Pour faire simple, on a tout centralisé car le monolithe a ses avantages. Cependant, tout centraliser, c’est aussi multiplier les risques (bugs, erreurs, risques de hack…), augmenter la lourdeur (temps de chargement par exemple), ralentir voir diminuer l’expérience client. ET ON NE VEUT PAS ÇA !
Nous souhaitons tout le contraire: une expérience client agréable, fluide et sans erreurs.
Vers une autre architecture: la création d’une SPA
L’idée c’est donc plutôt ça:
Ou dans un schéma plus compréhensible:
Plutôt que d’avoir une seule application, très lourde, très lente et unique source de problèmes, nous voulons séparer le front-end du back-end. En créant une SPA (Single-Page-Application), nous gagnons ainsi en vitesse, efficacité, lisibilité et satisfaction client. Nous sommes également convaincus que le travail des développeurs sera amélioré et que les tâches seront exécutées plus rapidement.
Cependant, ne faut pas détruire le travail accompli jusqu’alors mais le transposer ou le transformer; et par là, on entend presque toujours l’améliorer. Il faut donc y aller étape par étape.
Par où commencer?
Commencer par la messagerie était un très bon choix car c’est le coeur du produit Livementor. Les entrepreneurs échangent avec leur mentors, prennent des rendez-vous, partagent des liens, s’envoient des messages vocaux…
Grâce au travail de notre équipe de choc (Alexandre Dana, Alexandre Barbier, Emmanuel Julliot et Romain Vigo Benia), nous avons dans un premier temps externalisé notre messagerie en Vue.js. Evidemment, tout en conservant l’ancien produit, dans l’attente, un jour, d’avoir une (ou plusieurs) application(s) fonctionnelles et reliées entre elles par notre back-end.
Recoder une app ne se fait pas en un jour…
La migration, c’est tout le sujet. Les technologies changent de plus en plus vite et les start-ups n’ont pas nécessairement le temps ni la volonté de migrer leurs apps sur de nouveaux languages pour améliorer leur efficacité.
Tout le défi réside dans les choix d’architectures qui nous nous apporteront sécurité et flexibilité à l’avenir — et qui améliorera l’expérience des entrepreneurs comme des mentors.
