Frontend de Commerce Layer: ¿componentes drop-in o storefront completo?

Commerce Layer es API-first y exclusivamente headless. Ese es el propósito del producto y también lo que sorprende a los equipos después de firmar: Commerce Layer no incluye ninguna aplicación de storefront. Ni tema que instalar, ni editor de páginas, ni tienda lista para desplegar. En el frontend obtienes un conjunto de piezas, y convertirlas en un storefront funcional y editable es tarea tuya. Este artículo explica exactamente qué te da Commerce Layer en el frontend, dónde se queda corta cada opción y cómo cerrar esa brecha sin renunciar a Commerce Layer como núcleo transaccional.

Qué ofrece realmente Commerce Layer en el frontend

La superficie de frontend de Commerce Layer se compone de tres cosas, y conviene nombrarlas con precisión porque resuelven problemas distintos:

• Drop-in.js: una pequeña librería de componentes web ya construidos (carrito, precio, disponibilidad, líneas de pedido, enlace al checkout) que insertas en una página HTML existente con una etiqueta script y unos cuantos elementos personalizados.
• Componentes React y el JS SDK: una librería de componentes y un cliente tipado para equipos que construyen una aplicación a medida en React o Next.js contra la API de Commerce Layer.
• Un checkout alojado: un flujo de checkout operado por Commerce Layer al que rediriges, de modo que no tienes que construir tú mismo el camino de pago y creación del pedido.

Ninguna de estas piezas es un storefront. Son los elementos con los que montas uno. Esa distinción resume toda la decisión que tienes por delante.

Drop-in.js: útil para añadir comercio a una página que ya tienes

Drop-in.js es el camino más rápido y es honesto sobre su alcance. Si ya tienes un sitio de marketing, una página gestionada por un CMS o una build estática, y quieres añadir un botón de compra, un carrito y un precio que refleje el mercado del cliente, Drop-in.js lo consigue con muy poco código. Los componentes web se encargan por ti de las llamadas a la API y del estado del carrito.

Dónde se detiene: Drop-in.js te da widgets de comercio, no una experiencia de compra. Páginas de listado de productos, búsqueda facetada, navegación por categorías, la lógica de layout que hace navegable un catálogo, nada de eso viene incluido. Estás decorando una página que ya existe. Para un sitio de contenido que vende un puñado de productos, eso suele ser exactamente lo adecuado. Para un catálogo de miles de SKU, por sí solo no basta.

Componentes React y el JS SDK: más control, más mantenimiento

La vía React es donde vive la mayoría de los storefronts serios sobre Commerce Layer. Obtienes acceso tipado a toda la API, componentes de partida y libertad total sobre routing, renderizado y diseño. Si tu equipo trabaja con Next.js y le sobran ingenieros de frontend, es una base sólida.

El coste es la propiedad. Cada parte del storefront que no sea una llamada a la API de Commerce Layer pasa a ser código tuyo que construir y mantener: routing, SSR y caché, Core Web Vitals, accesibilidad, la librería de componentes, el modelo de contenido y el pipeline de despliegue. Commerce Layer no toma partido aquí de forma deliberada, lo que es libertad el primer día y una partida fija de mantenimiento durante los tres años siguientes. Es el mismo compromiso que arrastra cualquier desarrollo headless a medida; lo analizamos para stacks vecinos en los componentes drop-in de Adobe Commerce explicados.

El checkout alojado y dónde se acaba

El checkout alojado es una opción por defecto genuinamente útil. El pago, los impuestos y la creación del pedido son las partes de mayor riesgo a la hora de construir un storefront, y dejar que las gestione Commerce Layer elimina trabajo real. El límite es la continuidad de la experiencia: un checkout alojado es una redirección, así que el aspecto, la editabilidad y la analítica de ese paso viven en parte fuera de tu storefront. Para muchos comercios eso es aceptable. Para las marcas que entienden el checkout como parte de la experiencia, es una restricción que hay que planificar, no descubrir tarde.

El límite honesto: sin aplicación de storefront, sin editor visual

Dos hechos definen la decisión de frontend con Commerce Layer:

1. No existe una aplicación de storefront. Todas las opciones anteriores son conjuntos de componentes. El storefront, aquello que tus clientes navegan, es algo que construyes y operas tú.
2. No existe un editor visual. Una persona de marketing no puede cambiar un hero, reordenar una sección ni lanzar una landing page sin un desarrollador. Cada cambio de contenido es un cambio de código y un despliegue.

Ninguno de los dos es un defecto. Commerce Layer es un motor transaccional, y uno bueno. Pero si dabas por hecho que "plataforma de comercio headless" significaba "storefront incluido", ahí es donde se rompe la suposición y donde aparece discretamente el presupuesto de frontend.

Drop-in frente a storefront completo: comparativa rápida

• Añadir compra y carrito a una página existente. Drop-in.js: sí. React + SDK (a medida): excesivo. Frontend gestionado completo: sí.
• Listado de productos, navegación facetada. Drop-in.js: no. React + SDK (a medida): hay que construirlo. Frontend gestionado completo: incluido.
• Edición visual para marketing. Drop-in.js: no. React + SDK (a medida): no. Frontend gestionado completo: incluido.
• Core Web Vitals y accesibilidad gestionados por ti. Drop-in.js: no. React + SDK (a medida): tarea tuya. Frontend gestionado completo: incluido.
• Responsable del mantenimiento continuo. Drop-in.js: tú. React + SDK (a medida): tú. Frontend gestionado completo: la plataforma.

Mantén Commerce Layer como núcleo transaccional y consigue el storefront con Laioutr

Hay una tercera opción que la mayoría de los planteamientos de "drop-in frente a desarrollo a medida" pasan por alto. Puedes mantener Commerce Layer justo donde es fuerte, como tu núcleo transaccional API-first, y obtener el storefront y la editabilidad de una capa de frontend gestionada en lugar de construir ambas cosas por tu cuenta.

Eso es lo que hace Laioutr. Laioutr es un frontend headless composable que se conecta a la API de Commerce Layer y te da las piezas que Commerce Layer deja fuera de forma deliberada: un storefront completo (listados, navegación, PDP, integración de checkout), un page builder visual para que marketing pueda cambiar páginas sin un despliegue, y Core Web Vitals y accesibilidad resueltos en la capa de plataforma. Como el frontend se entrega como servicio, esa partida de mantenimiento a tres años que acompaña a un desarrollo React a medida deja de ser tuya. Explicamos el modelo operativo detrás de esto en Frontend as a Service, y los detalles específicos de Commerce Layer en la página de frontend para Commerce Layer.

El contenido, la consistencia de marca y la sincronización multiidioma pasan entonces a vivir en la capa editable y no en tu código, que es la diferencia entre un storefront que custodian tus ingenieros y uno que tu equipo de contenido puede operar. Para una comparación directa de las vías do it yourself, consulta las opciones de frontend headless para Commerce Layer comparadas.

Cómo decidir

• Sitio de contenido que vende unos pocos productos: Drop-in.js probablemente sea suficiente. Lánzalo.
• Catálogo completo, equipo de frontend sólido y ganas de asumir el stack: React más el SDK es un desarrollo legítimo. Presupuesta el mantenimiento con honestidad.
• Catálogo completo, quieres que marketing edite páginas y no quieres asumir la infraestructura de frontend: mantén Commerce Layer como backend y pon encima un frontend gestionado.

FAQ

¿Commerce Layer incluye un storefront? No. Commerce Layer ofrece los componentes web Drop-in.js, una librería de componentes React con un JS SDK y un checkout alojado. La aplicación de storefront en sí es algo que construyes o aportas.

¿Puede marketing editar un storefront de Commerce Layer sin desarrolladores? No con las herramientas propias de Commerce Layer. No hay editor visual, así que cada cambio de contenido es un cambio de código. Una capa de frontend gestionada con un page builder visual añade esa capacidad.

¿Basta con Drop-in.js para una tienda completa? Para un sitio de contenido con pocos productos, a menudo sí. Para un catálogo grande que necesita páginas de listado, búsqueda facetada y navegación por categorías, Drop-in.js es un complemento, no un storefront.

¿Tengo que hacer un replatforming para añadir un frontend gestionado? No. Commerce Layer permanece como tu núcleo transaccional. Laioutr se conecta a su API y aporta encima el storefront y la capa de edición, de modo que el backend no cambia.

¿Y los Core Web Vitals y la accesibilidad? En un desarrollo React a medida son responsabilidad tuya. En un frontend gestionado se resuelven en la capa de plataforma, incluidos componentes WCAG Ready y hosting en la UE.

Siguiente paso

Si trabajas con Commerce Layer y el presupuesto de frontend es la parte que no deja de crecer, habla con el equipo de Laioutr y trazaremos un storefront sobre tu configuración actual de Commerce Layer, sin necesidad de cambiar el backend.