Este es el complemento técnico de nuestro caso práctico sobre la salida de G.R.A.M.S Styling de WooCommerce. La migración está en curso: la arquitectura que describimos a continuación está construida, cargada con los datos reales y funciona detrás de Cloudflare Access hasta el lanzamiento.
Antes y después
Con WooCommerce, un único servidor PHP lo hacía todo: generaba cada página, ejecutaba la base de datos y alojaba decenas de plugins para monedas, envíos, complementos de producto, caché, búsqueda, correo, sincronización con marketplaces y más. Cada función era código de terceros que compartía un mismo proceso y una misma tabla de opciones en la base de datos, y cada visitante esperaba a ese servidor.
La nueva arquitectura separa tres cosas. El frontal funciona en Cloudflare Workers, cerca del visitante, y sirve páginas en caché. El motor de comercio, Medusa, funciona en un servidor pequeño y solo responde a las peticiones que lo necesitan: carritos, pago, cuentas y el panel de administración. Todo lo específico de esta tienda está escrito como módulos de Medusa, versionados y probados como cualquier otro código. El diagrama de arriba muestra las dos configuraciones lado a lado.
El motor de comercio: Medusa v2
Medusa nos dio las piezas que necesita una tienda y nada más: regiones y monedas, carritos, pedidos, preparación de envíos, clientes, una interfaz de administración y un sistema de módulos para ampliarlo todo. Funciona como una pila de Docker Compose con Postgres y Redis, gestionada con Coolify en un servidor de 2 vCPU. Un flujo de GitHub Actions compila y analiza la imagen en cada merge, y el servidor solo la descarga, así que un despliegue tarda alrededor de minuto y medio. La base de datos se vuelca cada hora y se copia fuera del servidor, y la restauración está probada.
El comportamiento propio de la tienda reside en un conjunto de módulos con licencia MIT que escribimos para que puedan reutilizarse en otras tiendas Medusa:
- Gastos de envío calculados a partir del peso del carrito y de una tabla de tarifas por país, con las mismas reglas que la tienda ha usado siempre.
- Complementos de producto (kits de montaje, placas laterales, accesorios) como variantes reales con su propio precio.
- Pagos con PayPal y Revolut mediante los SDK oficiales, con webhooks verificados y reembolsos.
- Contraseñas de clientes verificadas contra los hashes de WordPress en el primer inicio de sesión y actualizadas de forma transparente, para que nadie tenga que restablecer nada.
- Correo transaccional a través del buzón que la tienda ya utiliza.
- Cloudflare Turnstile en todos los formularios públicos, que en producción bloquea la petición ante cualquier fallo de verificación.
- Herramientas de pedidos: cobro, envío con seguimiento, cajas predefinidas, bultos por pedido y notas del equipo.
- Un tablero de producción por sede, donde los pedidos de marketplaces llegan como tarjetas.
- Tarifas de mensajería en tiempo real, reserva en un clic y almacenamiento de etiquetas.
- Un pequeño CMS para páginas, textos del sitio, el blog y la galería de coches de clientes, con traducciones.
- Feeds de productos para Google Merchant Center, Meta y Pinterest.
- Un asistente de compra con IA que relaciona un coche y una pieza con la categoría y las variantes correctas, con un selector sencillo como alternativa.
El frontal: Next.js 16 en Cloudflare Workers
El frontal es una aplicación Next.js con App Router desplegada como Cloudflare Worker, con páginas en caché en el edge que se revalidan en segundo plano, de modo que el motor de comercio solo recibe una pequeña parte del tráfico. La URL indica el mercado (/uk, /eu, /us, y variantes de idioma como /eu-fr), con canonical y hreflang por mercado. Un middleware gestiona las redirecciones desde la antigua tienda, la sugerencia de región por país, la cookie de idioma y las cabeceras de seguridad.
El blog es un sitio estático independiente que se regenera automáticamente cuando un editor guarda una entrada en el panel de Medusa. El tablero de los talleres es una página estática detrás de Cloudflare Access.
Cómo se migraron los datos
Cada registro importado de WooCommerce conserva su identificador original en los metadatos, así que la comparación entre la tienda antigua y la nueva puede repetirse en cualquier momento: productos, variantes, precios, pesos, clientes, pedidos, pagos, reembolsos y números de seguimiento se comprobaron por id, y la última ejecución no mostró diferencias en los precios. Los pedidos realizados en la antigua tienda antes del lanzamiento se importan uno a uno.
Qué volveríamos a hacer
Esta es la arquitectura que ahora proponemos a cualquier empresa que necesite una tienda con alcance global, velocidad en el edge y orientación por mercado, con la calidad de una tienda de nivel Shopify y sin ceder un porcentaje de cada venta. Headless fue la decisión correcta para este catálogo. Las reglas de envío, los complementos y los acabados del propietario no encajaban en ninguna plataforma alojada, y escribirlos como módulos pequeños permitió probar cada uno por separado. Llevar el frontal a Workers eliminó toda una categoría de trabajo de alojamiento. Y conservar los identificadores antiguos convirtió cada auditoría en un script en lugar de una conjetura.