BigCommerce Catalyst y Makeswift frente a un frontend agnóstico del backend

BigCommerce ha dedicado los últimos dos años a reconstruir su relato sobre el storefront. Catalyst es el nuevo framework de storefront, una base de Next.js y React que se comunica con la Storefront GraphQL API de BigCommerce. Makeswift, el editor visual que BigCommerce adquirió en 2024, se sitúa por encima como la capa en la que marketing edita páginas sin abrir un ticket a desarrollo. Juntos sustituyen el antiguo enfoque de temas Stencil por algo que se parece mucho más al composable commerce moderno. Para un equipo que ya ha apostado por BigCommerce como backend, eso es un avance real. La decisión que merece una pausa es otra: ambas herramientas están construidas para funcionar con el backend de BigCommerce, y solo con ese backend. Este artículo analiza qué implica ese acoplamiento y cuándo un frontend agnóstico del backend encaja mejor.

Qué son realmente Catalyst y Makeswift

Catalyst es el framework de storefront de BigCommerce. Se distribuye como una aplicación Next.js (React) conectada a la Storefront GraphQL API, con una librería de componentes y un storefront de referencia funcional listo desde el primer momento. Es el sucesor moderno de Stencil, el antiguo framework de temas de BigCommerce basado en Handlebars, y el camino que BigCommerce señala hoy a los equipos para storefronts headless y composable.

Makeswift es un page builder visual. BigCommerce lo adquirió en 2024 y lo posicionó como la capa de edición visual para Catalyst: marketing compone y edita páginas construidas con componentes React, sin tocar código, mientras desarrollo mantiene el control de los componentes que hay debajo. Si has seguido la categoría en general, el patrón te resultará familiar. Es la misma separación entre componentes gestionados por desarrollo y composición gestionada por marketing que define una Frontend Management Platform.

Ambas son sólidas. Catalyst es una mejora real frente a los temas Stencil mantenidos a mano, y Makeswift cierra la brecha de edición visual que suelen abrir los setups headless. La cuestión no es la calidad. Es el acoplamiento.

La cuestión del acoplamiento

Catalyst lee sus datos de la Storefront GraphQL API de BigCommerce. Makeswift edita páginas dentro de ese mismo contexto. Es una decisión de diseño y, para un equipo comprometido con BigCommerce, es exactamente lo que quieres: integración estrecha, un solo proveedor, un camino con soporte. La contrapartida es que el frontend que construyes es un frontend de BigCommerce. Si el panorama del backend cambia más adelante, una filial en otra plataforma, una unidad B2B que necesita commercetools, la decisión de abandonar BigCommerce por completo, el storefront de Catalyst no te acompaña. Toca reconstruir el frontend sobre el nuevo backend.

Un frontend agnóstico del backend invierte esa relación. En lugar de que el storefront lea directamente de la API de un único backend, una Frontend Management Platform se sitúa como capa propia y se conecta al backend a través de un data layer que normaliza los datos de producto, precio, inventario y pedidos en un único esquema de componentes. Hoy detrás puede estar BigCommerce. En dos años puede estar otro backend, sin reconstruir el storefront. Comparamos el conjunto más amplio de opciones en Opciones de frontend headless para BigCommerce comparadas; este artículo trata específicamente del camino de Catalyst y Makeswift frente a esa capa agnóstica.

Catalyst más Makeswift frente a un frontend agnóstico del backend

Cuándo Catalyst más Makeswift es la decisión correcta

Si BigCommerce es tu backend y no tienes ningún plan realista de cambiarlo, Catalyst más Makeswift es una elección razonable y bien respaldada. Obtienes integración first-party, un framework mantenido por el proveedor y un editor visual pensado para él. Un equipo de React capaz, que quiere gestionar directamente el código del storefront y no tiene problema en seguir las actualizaciones de Catalyst y Next.js, será productivo rápido. El acoplamiento a BigCommerce solo es un coste si tu backend pudiera cambiar. Si no va a cambiar, es simplemente la forma de la plataforma que elegiste.

Cuándo tiene más sentido un frontend agnóstico del backend

La capa agnóstica se gana su sitio cuando el backend no es una cuestión cerrada. Señales habituales: gestionas más de un backend de commerce entre marcas o regiones, estás evaluando un cambio de backend pero no quieres reconstruir el frontend como parte de ello, o quieres mantener reversible la decisión de arquitectura. Es la misma razón por la que los equipos desacoplan la modernización del frontend del replatforming del backend, más sobre esto en Replatforming de BigCommerce sin reconstruir el frontend y en alternativas a BigCommerce. Con un frontend headless composable entregado como capa Frontend as a Service gestionada, las actualizaciones de framework, el hosting y los parches de seguridad son trabajo de la plataforma en lugar de trabajo de sprint de tu equipo, y el mismo storefront funciona sobre cualquier backend que conectes.

Para los equipos de ingeniería, la diferencia práctica está en un solo punto: dónde se nombra el backend.

# Catalyst: los componentes leen directamente la Storefront API de BigCommerce
product = bigcommerce.storefront.query(productId)

# Agnóstico del backend: los componentes leen un esquema normalizado,
# el backend se resuelve en el data layer
product = orchestr.resolve("Product", productId)   # BigCommerce hoy, otro backend más adelante

El componente que renderiza una página de detalle de producto no cambia cuando cambia el backend. Solo cambia el resolver que hay detrás del esquema.

Rutas de migración: de Stencil a Catalyst o de Stencil a un frontend gestionado

Los equipos que siguen con temas Stencil antiguos se enfrentan a esta bifurcación de forma directa. Migrar de Stencil a Catalyst te mantiene dentro de BigCommerce y te lleva a un framework de React moderno que después mantienes tú. Migrar de Stencil a un frontend gestionado y agnóstico del backend también moderniza el storefront, pero traslada el mantenimiento de los cimientos del frontend a una plataforma y deja el backend intercambiable. Ambas opciones son válidas. La correcta depende de cuánta certeza tengas sobre quedarte en BigCommerce.

Checklist de decisión

Repasa esto antes de comprometerte con una de las dos vías:

• [ ] ¿Es BigCommerce una decisión cerrada para los próximos de tres a cinco años, o está en revisión?
• [ ] ¿Gestionas, o esperas gestionar, más de un backend de commerce entre marcas o mercados?
• [ ] ¿Tienes un equipo de React listo para asumir las actualizaciones de Catalyst y Next.js a largo plazo?
• [ ] ¿Necesita marketing edición visual y importa que ese editor esté atado a un único backend?
• [ ] Si abandonas Stencil, ¿quieres que la reconstrucción del frontend sea reutilizable si el backend cambia más adelante?
• [ ] ¿El mantenimiento del framework y de la seguridad es algo que tu equipo quiere asumir, o prefiere delegarlo a una plataforma?

Conclusión

Catalyst y Makeswift son buenas herramientas y, para un equipo comprometido con BigCommerce, suponen una mejora clara frente a Stencil. Lo único que no te dan es flexibilidad de backend, porque nunca fue su propósito. Si tu backend está decidido, eso no es un problema. Si no lo está, un frontend agnóstico del backend hace que el storefront que construyes hoy sobre BigCommerce siga siendo utilizable mañana sobre otro backend. El primer paso habitual es una llamada técnica breve para mapear qué datos de BigCommerce necesita realmente tu storefront y si la capa agnóstica merece la pena en tu caso.