BigCommerce Catalyst et Makeswift face à un frontend agnostique du backend

BigCommerce a reconstruit sa stratégie de storefront ces deux dernières années. Catalyst est le nouveau framework de storefront, une base sur Next.js et React qui communique avec la BigCommerce Storefront GraphQL API. Makeswift, l'éditeur visuel que BigCommerce a racheté en 2024, se place au-dessus comme la couche où le marketing modifie des pages sans ticket développeur. Ensemble, ils remplacent l'ancienne approche des thèmes Stencil par quelque chose qui ressemble bien davantage au commerce composable moderne. Pour une équipe déjà engagée sur BigCommerce comme backend, c'est un vrai progrès. La décision qui mérite qu'on ralentisse est autre : les deux outils sont conçus pour fonctionner avec le backend BigCommerce, et uniquement ce backend. Cet article examine ce que signifie ce couplage, et quand un frontend agnostique du backend est le meilleur choix.

Ce que sont réellement Catalyst et Makeswift

Catalyst est le framework de storefront de BigCommerce. Il se présente comme une application Next.js (React) reliée à la Storefront GraphQL API, avec une bibliothèque de composants et un storefront de référence fonctionnel dès le départ. C'est le successeur moderne de Stencil, l'ancien framework de thèmes de BigCommerce basé sur Handlebars, et la voie vers laquelle BigCommerce oriente aujourd'hui les équipes pour les storefronts headless et composables.

Makeswift est un constructeur de pages visuel. BigCommerce l'a racheté en 2024 et l'a positionné comme la couche d'édition visuelle de Catalyst : le marketing compose et modifie des pages construites à partir de composants React, sans toucher au code, tandis que les développeurs gardent le contrôle des composants en dessous. Qui suit la catégorie reconnaît le schéma. C'est la même séparation entre composants détenus par les développeurs et composition détenue par les marketeurs qui définit une Frontend Management Platform.

Les deux sont solides. Catalyst est une vraie amélioration par rapport aux thèmes Stencil maintenus à la main, et Makeswift comble le manque d'édition visuelle que les configurations headless ouvrent d'habitude. La question n'est pas la qualité. C'est le couplage.

La question du couplage

Catalyst lit ses données depuis la BigCommerce Storefront GraphQL API. Makeswift modifie les pages dans ce même contexte. C'est voulu, et pour une équipe engagée sur BigCommerce c'est exactement ce que tu veux : une intégration serrée, un seul fournisseur, une voie supportée. Le compromis, c'est que le frontend que tu construis est un frontend BigCommerce. Si le tableau backend change plus tard, une marque filiale sur une autre plateforme, une unité B2B qui a besoin de commercetools, ou la décision de quitter complètement BigCommerce, le storefront Catalyst ne te suit pas. Tu reconstruis le frontend sur le nouveau backend.

Un frontend agnostique du backend inverse cette relation. Au lieu que le storefront lise directement l'API d'un seul backend, une Frontend Management Platform se place comme sa propre couche et se connecte au backend via une couche de données qui normalise les données de produit, de prix, de stock et de commande dans un schéma de composants unique. BigCommerce peut se trouver derrière aujourd'hui. Un autre backend peut se trouver derrière dans deux ans, sans reconstruire le storefront. Nous avons comparé l'ensemble plus large des choix dans les options de frontend headless BigCommerce comparées. Cet article porte précisément sur la voie Catalyst et Makeswift face à cette couche agnostique.

Catalyst plus Makeswift face à un frontend agnostique du backend

Quand Catalyst plus Makeswift est le bon choix

Si BigCommerce est ton backend et que tu n'as aucun projet réaliste de changer, Catalyst plus Makeswift est un choix raisonnable et bien supporté. Tu obtiens une intégration first-party, un framework maintenu par le fournisseur et un éditeur visuel conçu pour lui. Une équipe React compétente qui veut posséder directement le code du storefront, et qui est à l'aise avec le suivi des mises à jour de Catalyst et de Next.js, sera vite productive. Le couplage à BigCommerce n'est un coût que si ton backend pouvait changer. S'il ne changera pas, c'est simplement la forme de la plateforme que tu as choisie.

Quand un frontend agnostique du backend a davantage de sens

La couche agnostique gagne sa place quand le backend n'est pas une question tranchée. Signaux fréquents : tu exploites plus d'un backend de commerce entre marques ou régions, tu évalues un changement de backend mais ne veux pas reconstruire le frontend au passage, ou tu veux garder la décision d'architecture réversible. C'est la même raison qui pousse les équipes à découpler la modernisation du frontend du replatforming du backend, plus de détails dans le replatforming BigCommerce sans reconstruction du frontend et dans les alternatives à BigCommerce. Avec un frontend headless composable livré comme couche Frontend as a Service gérée, les mises à jour de framework, l'hébergement et les correctifs de sécurité sont un travail de plateforme plutôt que le travail de sprint de ton équipe, et le même storefront tourne sur le backend que tu connectes.

Pour les équipes d'ingénierie, la différence pratique tient à un seul endroit : là où le backend est nommé.

# Catalyst : les composants lisent directement la BigCommerce Storefront API
product = bigcommerce.storefront.query(productId)

# Agnostique du backend : les composants lisent un schéma normalisé,
# le backend est résolu dans la couche de données
product = orchestr.resolve("Product", productId)   # BigCommerce aujourd'hui, un autre backend plus tard

Le composant qui rend une page de détail produit ne change pas quand le backend change. Seul le résolveur derrière le schéma change.

Chemins de migration : Stencil vers Catalyst, ou Stencil vers un frontend géré

Les équipes sur d'anciens thèmes Stencil font face directement à cette bifurcation. Migrer de Stencil vers Catalyst te garde à l'intérieur de BigCommerce et te fait passer à un framework React moderne que tu maintiens ensuite. Migrer de Stencil vers un frontend géré agnostique du backend modernise aussi le storefront, mais confie l'entretien du socle frontend à une plateforme et garde le backend interchangeable. Les deux sont valides. Le bon dépend de ta certitude à rester sur BigCommerce.

Liste de contrôle pour décider

Passe en revue ceci avant de t'engager dans un sens ou dans l'autre :

• [ ] BigCommerce est-il acté pour les trois à cinq prochaines années, ou en cours de révision ?
• [ ] Exploites-tu, ou prévois-tu d'exploiter, plus d'un backend de commerce entre marques ou marchés ?
• [ ] As-tu une équipe React prête à posséder les mises à jour de Catalyst et de Next.js sur le long terme ?
• [ ] Le marketing a-t-il besoin d'édition visuelle, et importe-t-il que cet éditeur soit lié à un seul backend ?
• [ ] Si tu quittes Stencil, veux-tu que la reconstruction du frontend soit réutilisable si le backend change plus tard ?
• [ ] L'entretien du framework et de la sécurité est-il quelque chose que ton équipe veut posséder, ou confier à une plateforme ?

À retenir

Catalyst et Makeswift sont de bons outils, et pour une équipe engagée sur BigCommerce ce sont une amélioration nette par rapport à Stencil. La seule chose qu'ils ne te donnent pas, c'est la flexibilité du backend, car ils n'ont jamais été pensés pour cela. Si ton backend est acté, ce n'est pas un problème. Sinon, un frontend agnostique du backend garde le storefront que tu construis aujourd'hui sur BigCommerce utilisable demain sur un autre backend. La première étape habituelle est un court échange technique pour cartographier quelles données BigCommerce ton storefront utilise vraiment, et si la couche agnostique en vaut la peine pour ta configuration.