5 Plataformas de E-commerce Open Source para Desarrolladores

Para los ingenieros frontend que están construyendo un storefront headless en 2026, los backends de comercio open source más sólidos a evaluar son Medusa, Saleor, Vendure, Sylius y Shopware. Cada uno es API-first, se mantiene activamente y se integra de forma limpia con un storefront basado en Next.js u otro framework de React — pero difieren considerablemente en el runtime del lenguaje, la forma de la API (REST vs GraphQL), el modelo de licenciamiento y la carga operativa que asumes al hacer self-hosting. Este artículo existe para ayudarte a preseleccionar una opción para un proyecto al que estás a punto de dedicar semanas de trabajo de integración y años de mantenimiento.

WooCommerce, Magento y PrestaShop merecen un reconocimiento honesto aquí: son ecosistemas maduros y ampliamente desplegados, con vastos marketplaces de plugins y herramientas para comerciantes que las plataformas mencionadas a continuación aún no han igualado. Pero su centro de gravedad es el mundo de WordPress y las plantillas de administración, no los storefronts orientados a APIs escritos en TypeScript. Si tu storefront es una aplicación Next.js que consume un SDK tipado o un endpoint GraphQL, las cinco plataformas a continuación son la lista corta relevante. Si tu storefront es un sitio CMS con plantillas administrado por un equipo de marketing, este no es el artículo que necesitas.

El comercio headless ya no es una tendencia que haya que vender — es la arquitectura por defecto para los storefronts greenfield en este momento. La pregunta no es si desacoplar el storefront del motor de comercio, sino qué motor te ofrece la mejor experiencia de desarrollo para los años de trabajo en funcionalidades que vendrán después.

Cómo elegir: una tabla comparativa

La forma más rápida de reducir la lista de candidatos es comparar las plataformas en las dimensiones que realmente le importan a un desarrollador de storefronts. La tabla a continuación resume los cinco candidatos; los recuentos de estrellas y las versiones de lanzamiento cambian constantemente, así que tómalos como punto de partida y verifica en la página de releases de GitHub de cada proyecto antes de comprometerte.

Dos columnas merecen atención especial. La columna de licencia no cuenta toda la historia: Vendure y Shopware incluyen un core con licencia MIT completamente funcional en producción, junto con ofertas comerciales de plataforma gestionada con licencia separada. Esto es relevante para la evaluación del presupuesto, no un truco — el core open source es genuinamente utilizable sin pagar por el nivel de plataforma. La columna de footprint de self-hosting refleja los servicios mínimos que operarás en producción, y es donde Saleor se diferencia de forma significativa de las opciones basadas en Node.

Medusa — Comercio headless en Node.js/TypeScript con módulos y workflows de v2

Medusa es un backend de comercio headless en Node.js/TypeScript cuya versión v2 reestructuró la plataforma en torno a módulos de comercio independientes — productos, carrito, pedidos, inventario, precios — cada uno de los cuales puede reemplazarse por una implementación personalizada o un servicio de terceros. Consulta la documentación oficial de v2 para conocer la arquitectura de módulos y workflows.

Para un ingeniero frontend, el resultado es la plataforma más composable de las cinco aquí presentadas. El código del storefront se comunica con el servidor Medusa a través de un cliente JavaScript tipado; la personalización del backend se realiza escribiendo módulos y workflows en TypeScript que pueden vivir en el mismo monorepo que el resto de los servicios de tu equipo si así lo deseas. El starter oficial de Next.js en la documentación de Medusa te proporciona un storefront funcional con flujos de carrito, checkout y cuenta de usuario con un solo comando create-medusa-app.

Donde Medusa destaca:

• Alineación de tipos de extremo a extremo. El servidor es TypeScript; el SDK del storefront es TypeScript; los módulos personalizados son TypeScript. No hay un paso de codegen entre los esquemas y los tipos del storefront.
• Workflows. Medusa v2 expone un primitivo de workflow explícito para operaciones de comercio de múltiples pasos (realizar pedido, devolución, etc.), lo que facilita razonar sobre la lógica de larga duración y compensable en comparación con cadenas de transacciones implícitas.
• El desarrollo local es sencillo. Un único proceso Node contra PostgreSQL, más Redis para trabajos en segundo plano.

Donde Medusa requiere atención:

• REST-first. La API principal de Medusa es REST. Los storefronts que prefieren un único endpoint GraphQL y tipos generados por codegen encontrarán Saleor más natural.
• Migración de v1 a v2. Las bases de código que aún están en Medusa v1 enfrentan un trabajo de migración no trivial; el sistema de módulos, el admin y las APIs cambiaron sustancialmente.

Elige Medusa si tu equipo es nativo en TypeScript, quieres plena propiedad de la personalización en tu propio lenguaje y la ergonomía de REST + SDK tipado te resulta adecuada. Descarta Medusa si quieres una capa de datos exclusivamente GraphQL o necesitas un conjunto profundo de herramientas de administración y merchandising listas para usar desde el primer día.

Saleor — Comercio headless GraphQL-first sobre Python/Django

Saleor es una plataforma de comercio headless en Python/Django con una API GraphQL-first. Cada operación de comercio — consultas de productos, mutaciones de checkout, gestión de pedidos, cuentas de clientes — pasa por un único endpoint GraphQL versionado, documentado en la referencia de la API de Saleor. El código base tiene licencia BSD-3-Clause; consulta el archivo LICENSE en GitHub.

El diseño GraphQL-first importa principalmente en la capa del storefront. Un storefront Next.js puede colocar sus requisitos de datos junto a sus componentes usando urql, Apollo o graphql-request, ejecutar graphql-codegen contra el esquema de Saleor y obtener hooks completamente tipados de consultas y mutaciones sin necesidad de escribir una capa adaptadora REST separada. Una consulta típica para una página de producto tiene este aspecto:

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

Esa única consulta devuelve exactamente lo que la página renderiza — sin overfetching, sin una llamada de inventario separada, sin un helper de formato de precios que diverja de la representación de moneda del servidor. Saleor también publica un ejemplo oficial de storefront en Next.js (repositorio del storefront) que puedes hacer fork en lugar de construir desde cero.

Donde Saleor requiere atención:

• Footprint operativo. Saleor en self-hosting necesita Python, PostgreSQL, Redis y un proceso worker de Celery para tareas asíncronas. Esto es más pesado que una combinación de Node + Postgres y vale la pena tenerlo en cuenta si tu equipo no opera ya un stack Python.
• Disciplina en el versionado del esquema. Una plataforma GraphQL-first significa que los cambios de esquema que rompen la compatibilidad son visibles. Saleor publica nuevas versiones menores con notas de migración claras, pero los storefronts que no fijan el esquema y regeneran los tipos sufrirán fallos silenciosos tras las actualizaciones.

Elige Saleor si quieres un único endpoint GraphQL, te sientes cómodo operando un stack Python y tu equipo de storefront domina los clientes GraphQL y el codegen. Descarta Saleor si tu equipo no tiene experiencia operativa en Python y prefieres mantener todo el stack en Node.

Vendure — Framework TypeScript/NestJS con Core MIT y un nivel de Plataforma comercial

Vendure es un framework de comercio headless en TypeScript/NestJS con una API GraphQL y un admin basado en Angular. Es la única plataforma en esta comparación que incluye su API de plugins, la capa de servicios y las extensiones del esquema GraphQL en TypeScript con inferencia de tipos completa — lo que significa que los plugins personalizados y el código del storefront comparten un único lenguaje y modelo de tipos. La documentación de Vendure cubre el sistema de plugins, las APIs GraphQL duales de Shop/Admin y el modelo de datos.

El Core open source de Vendure (con licencia MIT) es un motor de comercio headless completamente funcional. La Vendure Platform comercial añade hosting gestionado, soporte empresarial y módulos adicionales, pero no es necesaria para ejecutar un storefront en producción. Esta separación vale la pena entenderla antes de adoptarlo: el Core es genuinamente completo, y “open source” no significa “demo con funcionalidades limitadas”.

Desde la perspectiva del storefront, Vendure expone dos APIs GraphQL — Shop para las operaciones públicas del storefront y Admin para las herramientas de back-office. Ambas son compatibles con introspección y codegen. NestJS sustenta el servidor, lo que significa que los plugins personalizados siguen el familiar patrón módulo-proveedor si tu equipo tiene experiencia con NestJS.

Donde Vendure brilla:

• TypeScript en todas partes. Servidor, plugins, extensiones de la UI de administración y storefront — un único sistema de tipos.
• Arquitectura de plugins limpia. Los campos personalizados, los hooks de ciclo de vida y las extensiones del esquema GraphQL son de primera clase, no añadidos a posteriori.
• Self-hosting ligero. Un único proceso Node contra PostgreSQL o MySQL. El flujo de inicio por defecto usa SQLite para el desarrollo local.

Donde Vendure presenta concesiones:

• Ecosistema más pequeño. En comparación con Saleor o Medusa, el catálogo de plugins e integraciones de terceros es más reducido. Tendrás que escribir más código de integración tú mismo.
• El admin es Angular. Si tu equipo planea personalizar intensamente la UI de administración y trabaja exclusivamente con React, esto supone un coste de cambio de contexto.

Elige Vendure si quieres el stack de comercio headless más nativo en TypeScript y con mayor seguridad de tipos disponible, y estás dispuesto a construir algunas integraciones tú mismo. Descarta Vendure si necesitas el marketplace de plugins más amplio desde el primer día o no puedes tolerar un admin en Angular.

Sylius — Framework de comercio en Symfony con REST y GraphQL vía API Platform

Sylius es un framework de ecommerce open source construido sobre Symfony (PHP). Está posicionado como un framework más que como una plataforma llave en mano: proporciona los primitivos de comercio (productos, canales, pedidos, promociones, carritos) y asume que los compondrás en la aplicación que tu negocio realmente necesita. La documentación de Sylius cubre el modelo de componentes y los bundles de Symfony.

Para los ingenieros frontend, Sylius importa por su capa de API. Sylius se integra con API Platform para exponer endpoints REST y GraphQL sobre su modelo de datos, lo que lo hace utilizable como backend headless para un storefront Next.js u otro storefront JavaScript. El storefront por defecto usa plantillas Twig — adecuado para builds tradicionales, prescindible si vas headless.

Donde Sylius gana:

• Profundidad de Symfony. Si tu organización domina Symfony, Sylius encaja en el ecosistema empresarial PHP más amplio de forma más natural que cualquier otra plataforma aquí.
• Personalización mediante idiomas del framework. Sobreescribe servicios, eventos y entidades usando patrones estándar de Symfony. Sin un DSL de plugins propietario.
• Licencia MIT, sin nivel comercial requerido. El código base completo de Sylius bajo MIT es sobre el que construyes.

Donde Sylius presenta concesiones:

• Runtime PHP. Un equipo de Next.js sin experiencia operativa en PHP hereda PHP-FPM, Composer y las herramientas de Symfony para el backend.
• Requiere más ensamblaje. Sylius es honesto sobre ser un framework. Tendrás que escribir más código del que escribirías con Medusa o Saleor para alcanzar la paridad de funcionalidades con una plataforma llave en mano.

Elige Sylius si tienes fluidez en Symfony en el equipo y quieres un framework de comercio que puedas moldear completamente a tu dominio. Descarta Sylius si tu equipo trabaja exclusivamente con JS y prefieres no ejecutar un runtime PHP junto a tus servicios Node.

Shopware 6 — Backend PHP/Symfony con herramientas profundas para comerciantes y un storefront Vue.js

La Community Edition con licencia MIT de Shopware 6 es un backend de comercio completo con opciones de despliegue tanto tradicionales como headless, que expone una REST Store API junto a su framework de storefront basado en Vue.js. Los planes comerciales Rise, Evolve y Beyond añaden hosting gestionado, capacidades avanzadas B2B y funcionalidades de soporte empresarial, pero el core open source es apto para producción sin licencia comercial. La documentación para desarrolladores de Shopware cubre la Store API, la Admin API y los sistemas de apps/plugins.

Shopware es la plataforma con mayor completitud de funcionalidades para comerciantes en esta comparación. El CMS “Shopping Experiences” proporciona un constructor de páginas drag-and-drop para páginas de marketing; el rule builder soporta precios dinámicos, reglas de envío y promociones sin código; las herramientas de administración son genuinamente profundas. Para un desarrollador que construye un storefront Next.js, la Store API es REST y está bien documentada, y existen starters de storefront Next.js de la comunidad que la consumen.

Donde Shopware gana:

• Herramientas para comerciantes listas para usar que ninguna de las plataformas orientadas al desarrollador mencionadas anteriormente iguala.
• Fuerte posición en el mercado europeo con un ecosistema de partners maduro.
• Headless híbrido. Puedes ejecutar el storefront Vue.js por defecto o ir completamente headless vía Store API.

Donde Shopware presenta concesiones:

• Footprint operativo de PHP + Elasticsearch. Más pesado de hacer self-hosting que las opciones basadas en Node.
• El sistema de plugins es PHP-céntrico. La personalización del backend es en PHP/Symfony, incluso si tu storefront es TypeScript.

Elige Shopware si necesitas funcionalidades sustanciales para comerciantes listas para usar y te sientes cómodo operando un stack Symfony/PHP. Descarta Shopware si tu equipo trabaja exclusivamente con JS y prefieres una opción más ligera y orientada al desarrollador como Medusa o Vendure.

Cuándo tiene sentido Spree en su lugar

Si Shopware te parece demasiado orientado a la empresa y tu equipo tiene experiencia con Ruby on Rails, Spree Commerce es una alternativa razonable. Tiene licencia MIT, está completamente orientado a APIs, soporta configuraciones multi-tienda y multi-vendor, y lleva el tiempo suficiente en el mercado como para que los patrones de Rails estén bien establecidos. La concesión es similar a la de Sylius: Ruby on Rails en lugar de Symfony, pero la misma forma de decisión — adoptar el ecosistema de un framework maduro del lado del servidor a cambio de un runtime no-JS.

Factores de decisión en el lado del frontend

En la capa de integración del storefront, cinco factores determinan si un backend resulta productivo o problemático: ergonomía de TypeScript, compatibilidad con Next.js, arranque en frío del entorno local, arquitectura de plugins y profundidad de la documentación.

Ergonomía de TypeScript y codegen. Medusa y Vendure incluyen SDKs de TypeScript que se alinean con los tipos del servidor sin un paso de generación separado. El esquema GraphQL de Saleor se consume mejor a través de graphql-codegen, lo que añade un paso de build pero produce hooks tipados excelentes. Sylius y Shopware requieren que modeles las respuestas de la API tú mismo o que uses clientes generados por la comunidad.

Compatibilidad con Next.js. Medusa y Saleor mantienen ejemplos oficiales de storefront en Next.js que funcionan con el App Router. Vendure tiene starters de la comunidad. Sylius y Shopware se consumen habitualmente desde storefronts Next.js mediante llamadas directas a la API o SDKs de la comunidad — funciona, pero tendrás que escribir más de la integración tú mismo.

Experiencia de desarrollo local. Medusa y Vendure ofrecen el arranque en frío más rápido — instala dependencias, ejecuta una migración, inicia el servidor y listo. Saleor está bien documentado pero es más pesado debido al requisito de Python + Redis + Celery; se recomienda Docker Compose. Shopware y Sylius asumen un entorno de desarrollo PHP funcional; las imágenes Docker lo simplifican, pero las piezas en movimiento son más numerosas.

Arquitectura de plugins y extensiones. Las cinco plataformas soportan extensiones personalizadas, pero la experiencia de desarrollo difiere. Los plugins de Vendure son módulos TypeScript con hooks de ciclo de vida con seguridad de tipos. Los módulos de Medusa v2 son clases TypeScript con un contrato claro. Saleor usa “apps” basadas en webhooks que se ejecutan como servicios separados — un límite de aislamiento más sólido, pero con mayor sobrecarga operativa. Sylius y Shopware usan los sistemas de bundles/plugins de Symfony.

Calidad de la documentación. Entre las cinco, Medusa, Saleor, Vendure y Shopware mantienen sitios de documentación con referencias de API, tutoriales y resúmenes de arquitectura razonablemente actualizados con los lanzamientos. La documentación de Sylius es exhaustiva, pero asume fluidez en Symfony.

Fallos del mundo real que sobreviven a cualquier elección de plataforma

Un modo de fallo común en producción en los storefronts headless — en todos los backends de este artículo — es el mismatch de hidratación de React en las páginas de producto, donde los precios renderizados en el servidor, los recuentos de inventario o las cadenas localizadas divergen de lo que el cliente renderiza después de obtener datos frescos. Otros patrones recurrentes: divergencia silenciosa del estado del carrito cuando el carrito del cliente y la sesión del servidor se desincroniza tras un fallo de red; scripts de proveedores de pago (Stripe, Adyen, PayPal) que no se cargan o inicializan y que solo se manifiestan como un botón de checkout bloqueado; y cambios de esquema que rompen la compatibilidad tras una actualización del backend, produciendo campos null crípticos en lugar de errores explícitos.

Estos fallos son agnósticos a la plataforma, pero varían en depurabilidad según cómo el backend expone el contexto de error en sus respuestas de API. Los errores GraphQL de Saleor incluyen códigos estructurados; las respuestas REST de Medusa incluyen tipos de error; Shopware y Sylius exponen el formato de error estructurado de Symfony. Independientemente de cuál elijas, instrumentar el storefront con herramientas de session replay como OpenReplay — para capturar el estado real del DOM, las solicitudes de red, los errores de consola y las interacciones del usuario que conducen a un carrito fallido o un checkout roto — cierra el ciclo entre “el usuario dice que el checkout está roto” y un informe de bug reproducible. El producto de session replay de OpenReplay está construido específicamente para esta categoría de depuración de frontend en producción.

Tomando la decisión

La lista corta se reduce rápidamente una vez que pesas la fluidez lingüística del equipo y la preferencia de la capa de datos del storefront. Un equipo nativo en TypeScript que construye un storefront Next.js con un SDK tipado debería evaluar Medusa primero y Vendure en segundo lugar. Un equipo que quiere un único endpoint GraphQL y está dispuesto a operar un stack Python debería evaluar Saleor. Un equipo fluido en Symfony debería evaluar Sylius para un build con forma de framework o Shopware para las herramientas de comerciante más completas. Ejecuta el quickstart local para tu uno o dos candidatos principales antes de comprometerte — una tarde de docker-compose up y un recorrido por el admin te dirá más que otra semana de lectura comparativa.

Preguntas Frecuentes

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.