De commercetools Frontend au backend-agnostique : gardez le frontend, ouvrez la stack

Vous avez choisi commercetools, vous avez construit un storefront sur commercetools Frontend (le produit anciennement connu sous le nom de Frontastic, vendu aujourd'hui aux cotes de Foundry), et il fonctionne. Le probleme n'est pas le storefront. Le probleme, c'est ce a quoi le storefront est discretement cable. Quand votre frontend est construit a l'interieur du produit frontend d'un fournisseur, le frontend et le backend commerce cessent d'etre deux decisions pour n'en former qu'une. Cet article explique comment garder le storefront que vous avez deja livre tout en refaisant du backend commerce un choix que vous pouvez rouvrir a tout moment.

Ce que "commercetools Frontend" couple reellement

commercetools Frontend est une couche frontend avec un parti pris. Elle vous donne un studio pour composer des pages, un ensemble de connecteurs de donnees et un runtime de rendu. C'est reellement utile, et c'est aussi la que le couplage commence. Le modele de composition des pages, la couche de recuperation des donnees et le pipeline de deploiement sont tous construits autour d'une hypothese : le backend commerce en dessous est commercetools.

Cette hypothese apparait a de petits endroits porteurs. Le modele d'extension d'API, la maniere dont l'etat du panier et du checkout circule dans le frontend, la forme des donnees produit et categorie que vos composants attendent, ce que le studio entend par "produit" : tout cela se mappe un a un sur l'API commercetools. Rien de tout cela n'est faux. C'est simplement non portable. Le storefront que vous avez construit est un storefront commercetools, pas un storefront qui utilise commercetools aujourd'hui par hasard.

Alors quand quelqu'un pose la question legitime "pourrions-nous faire tourner une partie du catalogue sur un autre backend, ou quitter commercetools dans deux ans", la reponse honnete dans un frontend couple au fournisseur est : pas sans reconstruire le frontend. Les deux decisions sont soudees ensemble.

Le risque de lock-in d'un frontend couple au fournisseur

Le lock-in n'est pas une faute morale du fournisseur, c'est une propriete d'une architecture. Un frontend couple a un seul backend porte quelques risques concrets qu'il vaut la peine de nommer clairement.

Le levier de prix passe au fournisseur. Quand le storefront ne peut pas tourner sans un backend precis, chaque discussion de renouvellement se fait depuis une position faible. Vous ne negociez pas sur un backend, vous negociez sur le cout de ne pas reconstruire tout votre frontend.

Dependance a la roadmap. Un nouveau comportement dans le storefront, une etape de checkout differente, une nouvelle regle de merchandising, un changement dans le rendu des bundles, attend souvent ce que le produit frontend expose. Vous avancez au rythme des releases du fournisseur, pas au votre.

Un point de defaillance architectural unique. Si le backend atteint une limite de scalabilite, change ses prix ou opere un virage strategique que vous ne suivez pas, vous en heritez, car il n'y a pas de couture pour l'echanger. Un choix best-of-breed pour la recherche, les paiements ou le fulfillment se defait facilement. Un backend soude au frontend, non.

Le savoir de l'equipe se concentre sur le fournisseur, pas sur votre produit. Chaque heure passee a apprendre le modele d'extension specifique d'un produit frontend est une heure non passee sur des competences frontend portables. Quand le couplage est serre, l'expertise de votre equipe est un actif qui ne paie que tant que vous restez.

Rien de tout cela ne signifie que commercetools est le mauvais backend. Pour beaucoup d'equipes, c'est le bon. Cela signifie que la charge, c'est le couplage, pas le fournisseur.

Le chemin de decouplage : garder le storefront, ouvrir le backend

La bonne nouvelle : decoupler n'est pas une reconstruction. Le storefront que vous avez livre, les composants, le design system, les structures de page, c'est la partie qui vaut la peine d'etre gardee. Ce qui change, c'est la couche en dessous. Le chemin comporte trois mouvements pratiques.

1. Poser un contrat de donnees entre le frontend et le backend

Aujourd'hui, vos composants parlent presque certainement commercetools directement, ou via les connecteurs du produit frontend, ce qui revient au meme une couche plus bas. Le premier mouvement est de definir un contrat stable et neutre vis-a-vis du backend sur ce dont le frontend a besoin : une forme produit, une forme panier, un flux de checkout, un objet client. Vos composants font leur rendu contre ce contrat. Un adaptateur fin mappe le contrat sur commercetools. Les specificites commercetools vivent desormais a un seul endroit au lieu d'etre dispersees dans chaque composant.

2. Sortir la composition des pages du studio du fournisseur

Le deuxieme mouvement est de posseder la couche de composition, la partie qui decide quelles sections apparaissent sur quelle page et avec quelles donnees. Dans une configuration couplee au fournisseur, cela vit dans le produit frontend et suppose le backend du fournisseur. La deplacer dans un composable headless frontend que vous controlez signifie que la structure des pages survit intacte a un changement de backend, car elle compose contre le contrat de donnees, pas directement contre commercetools.

3. Faire du backend un connecteur, pas une fondation

Une fois le contrat et la couche de composition a vous, le backend commerce devient un connecteur derriere l'adaptateur. commercetools reste s'il vous sert bien. Il peut aussi se tenir a cote d'un autre backend pour un catalogue, une region ou une business unit specifique, ou etre remplace entierement plus tard, sans que le frontend le remarque. Le storefront ne sait plus et ne se soucie plus de quel backend a repondu a la requete.

C'est le meme principe de composable storefront deja applique a la recherche, aux paiements et a la gestion des commandes : le systeme specialise garde la logique metier, le frontend possede la surface et reste interchangeable en dessous.

Backend-agnostique vs. frontend couple au fournisseur

• Dimension | Frontend couple au fournisseur | Frontend backend-agnostique
• Choix du backend | Fige sur un fournisseur | Interchangeable derriere un adaptateur
• Storefront en cas de changement de backend | Reconstruction | Garde, seul l'adaptateur change
• Multi-backend (region, business unit) | Rarement faisable | Supporte via un contrat de donnees
• Roadmap pour un nouveau comportement UI | Attend le produit frontend | L'equipe frontend livre directement
• Levier au renouvellement | Faible, l'alternative est la reconstruction | Plus fort, le backend est une piece remplacable
• Competences de l'equipe | Liees au modele d'un fournisseur | Competences frontend et contrat portables

FAQ

Devons-nous quitter commercetools pour devenir backend-agnostiques ? Non, et c'est justement le point. Backend-agnostique signifie que commercetools est un choix que vous continuez de faire parce qu'il fonctionne, pas une dependance dont vous ne pouvez pas sortir. La plupart des equipes decouplent d'abord et laissent commercetools tourner longtemps derriere l'adaptateur.

Decoupler signifie-t-il jeter le storefront que nous avons construit ? Non. Le storefront est l'actif que vous gardez. Decoupler change la couche en dessous : le contrat de donnees, la couche de composition et le connecteur backend. Les composants et le design system restent.

Un adaptateur, n'est-ce pas juste plus de code a maintenir ? C'est un adaptateur au lieu d'hypotheses commercetools dispersees dans chaque composant. C'est generalement moins a maintenir, et c'est la couture qui rend chaque decision backend future peu couteuse au lieu de catastrophique.

Combien de temps cela prend-il ? C'est incrementiel, pas une bascule big-bang. Vous pouvez introduire le contrat de donnees type de page par type de page, et faire tourner le chemin couple au fournisseur et le chemin decouple en parallele pendant la transition.

Et si nous sommes satisfaits de commercetools ? Alors decoupler paie quand meme, car cela transforme une dependance dure en dependance souple. Pouvoir partir est ce qui maintient une bonne relation bonne.

L'etat cible : une couche frontend backend-agnostique

Le point d'arrivee de ce chemin est un frontend qui est une couche a part entiere, pas un appendice du backend. Cette couche possede la composition des pages, le contrat de donnees et le rendu, et traite chaque backend, commerce, recherche, contenu, comme un connecteur derriere une interface stable. C'est exactement ce qu'est une Frontend Management Platform : l'endroit ou le storefront vit independamment de tout backend unique, gere comme un produit a part avec son propre rythme de releases.

Laioutr construit cette couche. Votre equipe continue de composer dans un studio, la difference est que le studio compose contre un contrat neutre vis-a-vis du backend. Ainsi, le storefront que vous avez construit sur commercetools continue de tourner pendant que le backend en dessous devient une decision que vous pouvez rouvrir quand cela a du sens. L'etape suivante, c'est que les changements de routine sur cette couche soient pris en charge par une agentic frontend management platform, pour que l'equipe frontend passe son temps sur la surface, pas sur la tuyauterie.

Prochaine etape

Vous tournez sur commercetools Frontend et vous vous demandez ce qu'il faudrait pour garder le storefront tout en ouvrant le backend ? Parlez a l'equipe Laioutr et nous mapperons votre configuration actuelle vers un frontend backend-agnostique, avec commercetools toujours en place jusqu'a ce que vous en decidiez autrement.