Passer du monolithe au headless commerce… dans la vraie vie !

Le headless fonctionne avec un backend découplé du frontend (qui fait appel au backend pour les règles métiers), pour permettre notamment l’omnicanalité. Par rapport au monolithe, il implique de nombreux avantages, mais aussi inconvénients. C’est un type d’architecture qui fait beaucoup parler de lui actuellement. Derrière le buzzword technique, quelles sont les implications de migrer vers du headless à partir d’un monolithe ?

La migration vers le headless en pratique

Première étape : mettre en place des APIs

On choisit souvent d’utiliser le monolithe seulement avec ses APIs (parfois très nombreuses), sans son front : on découple donc le front et le backend.

Pour le front, on choisit soit de faire du sur-mesure, soit d’utiliser de l’open source. Cette première étape permet de gagner en expérience utilisateur, fluidité d’interface et expérience en mobilité. On peut déjà envisager de brancher ses APIs à des bornes interactives ou à des caisses.

Cependant, cette première étape présente quelques inconvénients :

• Le backend reste un monolithe, car un seul code fait tout.
• Le front branché sur les APIs est très dépendant de ces dernières : si elles évoluent, le front sera cassé et ne fonctionnera plus. Les deux doivent continuer d’évoluer en même temps.
• Le système reste dépendant de la scalabilité de la performance et de la stabilité de l’API qui reste fournie par le monolithe.

Deuxième étape : introduire un backend for frontend

Les grands acteurs du e-commerce choisissent souvent d’introduire un backend for frontend entre les APIs du monolithe et les interfaces ou différents canaux (front, mobile, caisse, kiosque…) : cet élément intermédiaire fait office de traducteur entre les deux mondes – APIs historiques et interfaces utilisateurs. Ainsi, les différents canaux ne dialoguent jamais avec les APIs du monolithe, mais uniquement avec le backend for frontend : avec une API qui est indépendante – le front ignore les anciennes APIs.

Cette solution permet de faire évoluer le back indépendamment du front : on peut brancher ou supprimer certaines APIs et démanteler le monolithe vis-à-vis d’un élément indésirable (par exemple les produits), le tout sans toucher au front. Les solutions backend for frontend les plus courantes sont, entre autres, Apollo, AWS API Gateway ou Spring Boot.

Mais attention, cette approche introduit de nouvelles complexités. C’est un mille-feuilles qui continue de grossir, qui nécessite de maîtriser de nouvelles technologies et qui produit un « choc générationnel ».

Les impacts de la migration

Parmi les grands acteurs du top-20 du e-commerce, on observe certains résultats.

Côté organisation, on utilise des frontends (par exemple React), qui dialoguent avec des APIs ou du Server- side rendering (la génération de pages html côté serveur, pour une expérience utilisateur optimale), puis la solution backend for frontend comme Apollo, et l’Identity Access Management (IAM). Enfin, couplés à la solution backend for frontend, on trouve différents types de bases de données et les APIs historiques (ERP, APIs métiers, outils de gestion de contenu, outils e-commerce…).

De ce fait, la partie backend e-commerce devient minuscule par rapport à l’ensemble de l’écosystème technique, qui se rapproche alors de l’ingénierie.

Ce fonctionnement amène aussi de l’ingénierie côté frontend : ce dernier doit être pensé très finement pour de bonnes performances et expériences utilisateurs, mais aussi pour savoir où se trouvent la donnée froide (prédiction à la journée ou à l’heure) et la donnée chaude (évolution souvent à la minute qui nécessite de l’appeler et la calculer à chaque fois).

Après quoi, on construit l’expérience utilisateur en fonction de ces données chaudes et froides. Ce tri peut être effectué par un moteur de recherche, ou par une API métier : on raisonne au cas par cas pour savoir où sont les données et comment les appeler. Une charge mentale que les monolithes permettent d’éviter.

Le cas de l’encapsulation

On peut envisager de migrer, c’est-à-dire d’ajouter une brique e-commerce au frontend, sans changer le reste. On encapsule un morceau de nouvelle page dans l’ancien système.

Cette nouvelle ingénierie consiste à encapsuler plusieurs frontends dans un seul : c’est le micro-frontend.

Pour l’internaute, cette méthode est parfaitement « sans couture » : il ne voit qu’un seul écran, mais qui est en réalité un composite d’éléments provenant de plusieurs endroits.

Cette approche est pratiquée par de grands acteurs, qui recomposent leurs pages morceau par morceau, quand il est inenvisageable de refaire tout le front en une seule fois.