De commercetools Frontend a backend-agnostic: conserva el frontend, abre el stack

Elegiste commercetools, construiste un storefront sobre commercetools Frontend (el producto antes conocido como Frontastic, ahora comercializado junto a Foundry) y funciona. El problema no es el storefront. El problema es a qué está conectado el storefront sin que se note. Cuando tu frontend está construido dentro del producto de frontend de un proveedor, el frontend y el backend de comercio dejan de ser dos decisiones y pasan a ser una. Este artículo trata de cómo conservar el storefront que ya has puesto en producción mientras conviertes de nuevo el backend de comercio en una decisión revisable.

Qué acopla realmente «commercetools Frontend»

commercetools Frontend es una capa de frontend con una opinión. Te da un estudio para componer páginas, un conjunto de conectores de datos y un runtime de renderizado. Eso es genuinamente útil, y también es donde empieza el acoplamiento. El modelo de composición de páginas, la capa de obtención de datos y el pipeline de despliegue están construidos en torno a un supuesto: el backend de comercio de debajo es commercetools.

Ese supuesto aparece en sitios pequeños pero estructurales. El modelo de extensión de la API, la forma en que los carritos y el estado del checkout circulan por el frontend, la forma de los datos de producto y categoría que esperan tus componentes, la noción que tiene el estudio de lo que es un «producto»: todo mapea uno a uno con la API de commercetools. Nada de eso está mal. Simplemente no es portable. El storefront que construiste es un storefront de commercetools, no un storefront que hoy usa commercetools.

Así que cuando alguien hace la pregunta razonable, «¿podríamos ejecutar parte de este catálogo en otro backend, o salir de commercetools dentro de dos años?», la respuesta honesta dentro de un frontend acoplado al proveedor es: no sin reconstruir el frontend. Las dos decisiones están soldadas.

El riesgo de lock-in de un frontend acoplado al proveedor

El lock-in no es un fallo moral de un proveedor, es una propiedad de una arquitectura. Un frontend acoplado a un único backend conlleva unos cuantos riesgos concretos que conviene nombrar con claridad.

El poder de negociación en precio pasa al proveedor. Cuando el storefront no puede funcionar sin un backend concreto, cada conversación de renovación se produce desde una posición débil. No estás negociando por un backend, estás negociando por el coste de no reconstruir todo tu frontend.

Dependencia de la hoja de ruta. Un comportamiento nuevo en el storefront, un paso de checkout distinto, una nueva regla de merchandising, un cambio en cómo se renderizan los packs, suele quedar a la espera de lo que exponga el producto de frontend. Avanzas al ritmo de las releases del proveedor, no al tuyo.

Un único punto de fallo arquitectónico. Si el backend topa con un límite de escalado, un cambio de precios o un giro estratégico con el que no estás de acuerdo, lo heredas, porque no hay una costura por la que sustituirlo. Una elección best-of-breed para búsqueda, pagos o fulfilment es fácil de revertir. Un backend soldado al frontend no lo es.

El conocimiento del equipo se concentra en el proveedor, no en tu producto. Cada hora dedicada a aprender el modelo de extensión concreto de un producto de frontend es una hora que no se dedica a competencias de frontend portables. Cuando el acoplamiento es fuerte, la experiencia de tu equipo es un activo que solo rinde mientras te quedes.

Nada de esto significa que commercetools sea el backend equivocado. Para muchos equipos es el adecuado. Significa que el pasivo es el acoplamiento, no el proveedor.

El camino del desacoplamiento: conserva el storefront, abre el backend

La buena noticia es que desacoplar no es reconstruir. El storefront que pusiste en producción, los componentes, el design system, las estructuras de página, es la parte que merece la pena conservar. Lo que cambia es la capa que hay debajo. El camino tiene tres movimientos prácticos.

1. Pon un contrato de datos entre el frontend y el backend

Hoy tus componentes casi con seguridad hablan commercetools directamente, o a través de los conectores del producto de frontend, que es lo mismo una capa más abajo. El primer movimiento es definir un contrato estable y neutral respecto al backend para lo que necesita el frontend: una forma de producto, una forma de carrito, un flujo de checkout, un objeto de cliente. Tus componentes renderizan contra ese contrato. Un adaptador ligero mapea el contrato a commercetools. Las especificidades de commercetools viven ahora en un único sitio en lugar de repartidas por cada componente.

2. Saca la composición de páginas del estudio del proveedor

El segundo movimiento es ser dueño de la capa de composición, la parte que decide qué secciones aparecen en qué página y con qué datos. En un montaje acoplado al proveedor esto vive dentro del producto de frontend y da por supuesto el backend del proveedor. Trasladarlo a un frontend headless composable que tú controlas significa que la estructura de la página sobrevive intacta a un cambio de backend, porque compone contra el contrato de datos y no contra commercetools directamente.

3. Convierte el backend en un conector, no en un cimiento

Una vez que el contrato y la capa de composición son tuyos, el backend de comercio pasa a ser un conector detrás del adaptador. commercetools se queda si te está sirviendo bien. También puede convivir con otro backend para un catálogo, una región o una unidad de negocio concretos, o ser sustituido por completo más adelante, sin que el frontend se entere. El storefront ya no sabe ni le importa qué backend respondió a la consulta.

Es el mismo principio de composable storefront que ya se aplica a búsqueda, pagos y gestión de pedidos: el sistema especialista conserva la lógica de dominio, el frontend es dueño de la superficie y sigue siendo intercambiable por debajo.

Frontend backend-agnostic frente a frontend acoplado al proveedor

• Dimensión | Frontend acoplado al proveedor | Frontend backend-agnostic
• Elección de backend | Fijada a un proveedor | Intercambiable detrás de un adaptador
• Storefront ante un cambio de backend | Reconstrucción | Se conserva, solo cambia el adaptador
• Multi-backend (región, unidad de negocio) | Rara vez viable | Soportado mediante un contrato de datos
• Hoja de ruta para nuevo comportamiento de UI | Espera al producto de frontend | El equipo de frontend lo entrega directamente
• Poder de negociación en la renovación | Bajo, la alternativa es reconstruir | Mayor, el backend es una pieza reemplazable
• Competencias del equipo | Atadas al modelo de un proveedor | Competencias portables de frontend y de contrato

Preguntas frecuentes

¿Tenemos que dejar commercetools para ser backend-agnostic? No, y esa es justo la idea. Backend-agnostic significa que commercetools es una elección que sigues haciendo porque funciona, no una dependencia de la que no puedes salir. La mayoría de los equipos desacopla primero y mantiene commercetools funcionando detrás del adaptador durante mucho tiempo.

¿Desacoplar significa tirar el storefront que hemos construido? No. El storefront es el activo que conservas. El desacoplamiento cambia la capa que hay debajo: el contrato de datos, la capa de composición y el conector del backend. Los componentes y el design system se quedan.

¿No es un adaptador simplemente más código que mantener? Es un adaptador en lugar de supuestos de commercetools esparcidos por cada componente. Eso suele ser menos que mantener, y es la costura que hace que cada decisión futura sobre el backend sea barata en vez de catastrófica.

¿Cuánto tiempo lleva esto? Es incremental, no un corte de big bang. Puedes introducir el contrato de datos tipo de página a tipo de página, y ejecutar en paralelo el camino acoplado al proveedor y el desacoplado durante la transición.

¿Y si estamos contentos con commercetools? Entonces desacoplar sigue mereciendo la pena, porque convierte una dependencia dura en una blanda. Poder marcharte es lo que mantiene buena una buena relación.

El estado objetivo: una capa de frontend backend-agnostic

El punto final de este camino es un frontend que es una capa por derecho propio, no un apéndice del backend. Esa capa es dueña de la composición de páginas, del contrato de datos y del renderizado, y trata cada backend, de comercio, de búsqueda, de contenido, como un conector detrás de una interfaz estable. Eso es una Frontend Management Platform en esencia: el lugar donde el storefront vive con independencia de cualquier backend concreto, gestionado como un producto propio con su propio ritmo de releases.

Laioutr construye esa capa. Tu equipo sigue componiendo en un estudio; la diferencia es que el estudio compone contra un contrato neutral respecto al backend, de modo que el storefront que construiste sobre commercetools sigue funcionando mientras el backend de debajo pasa a ser una decisión que puedes revisar cuando tenga sentido. El siguiente paso es que los cambios rutinarios en esta capa los gestione una agentic frontend management platform, para que el equipo de frontend dedique su tiempo a la superficie y no a la fontanería.

Siguiente paso

¿Funcionas sobre commercetools Frontend y te preguntas qué haría falta para conservar el storefront y abrir el backend? Habla con el equipo de Laioutr y mapearemos tu montaje actual a un frontend backend-agnostic, con commercetools todavía en su sitio hasta que decidas lo contrario.