Desarrollar una app de Shopify en 2026 es una experiencia muy distinta a la de hace apenas tres años. Shopify ha reordenado su ecosistema de desarrollo alrededor de un stack oficial muy concreto —React, React Router, Polaris, GraphQL— y quien lo acepta avanza rápido, mientras que quien intenta nadar contra corriente paga un peaje constante en integración, revisión y mantenimiento. En Keliam acabamos de cerrar un desarrollo completo de app embebida para el admin de Shopify, y este artículo destila las decisiones de stack que tomamos, por qué las tomamos y qué haríamos igual (o distinto) en el próximo proyecto.
La tesis central es simple: en el desarrollo de apps de Shopify, el stack no se elige tanto como se adopta. Shopify publica un template oficial que resuelve OAuth, sesiones, webhooks y el andamiaje de una app embebida, y ese template marca el camino: TypeScript, React Router v7 como framework full-stack (el sucesor natural del célebre template de Remix), Polaris como sistema de diseño, Prisma como ORM y Vite como herramienta de build. Sobre esa base, las decisiones reales que quedan en tu mano son menos glamurosas pero más importantes: qué base de datos pones detrás de Prisma cuando sales de desarrollo, cómo tipas tus llamadas a la Admin API de GraphQL, cómo validas lo que entra por webhooks y cómo respetas los rate limits cuando procesas miles de pedidos. Vamos por partes.
1. Qué es hoy una app de Shopify (y por qué condiciona el stack)
Una app de Shopify moderna es, en esencia, una aplicación web independiente que se incrusta en el admin de la tienda mediante un iframe controlado por App Bridge, se autentica contra Shopify con OAuth y session tokens, y habla con la plataforma a través de la Admin API GraphQL y de webhooks. Tu app vive en tu propia infraestructura: Shopify no aloja tu código, aloja la relación con el merchant.
Este modelo condiciona todo. Necesitas un framework web con servidor (no vale un SPA puro), porque OAuth, webhooks y las llamadas autenticadas a la API se gestionan en backend. Necesitas que la UI se sienta nativa dentro del admin, lo que empuja hacia Polaris. Y necesitas persistencia propia para sesiones, configuración por tienda y cualquier dato de negocio que tu app gestione. Además, desde la retirada progresiva de la API REST como ciudadana de primera clase, el desarrollo es GraphQL-first: conviene asumirlo desde el primer día y montar el tooling en consecuencia. Si vienes del ecosistema de tiendas más que del de apps, nuestro repaso de las novedades de Shopify en 2026 da contexto de hacia dónde se mueve la plataforma.
2. El esqueleto: el template oficial de React Router v7, sucesor de Remix
Durante un par de años, el punto de partida canónico fue el template de Remix. Con la fusión de Remix en React Router v7 —el framework absorbió las capacidades full-stack de Remix: loaders, actions, SSR—, Shopify publicó el template sucesor: @shopify/shopify-app-react-router (nosotros trabajamos con la 1.1). Si hoy arrancas un proyecto con shopify app init, esto es lo que te da, y es exactamente lo que recomendamos usar.
¿Qué resuelve el template que no querrías resolver a mano? Prácticamente todo el andamiaje crítico: el flujo completo de OAuth e instalación, la gestión de session tokens para apps embebidas, el registro y verificación HMAC de webhooks, el scaffolding de Prisma para persistir sesiones, la integración con App Bridge y la estructura de rutas del admin. Son cientos de horas de trabajo propenso a errores de seguridad que Shopify mantiene por ti y actualiza con cada versión de la API.
La estructura mental de React Router v7 full-stack se aprende en un día si vienes de React: cada ruta puede tener un loader (datos en servidor, en tu caso llamadas a la Admin API), una action (mutaciones) y un componente. No hay estado global misterioso: los datos fluyen del loader al componente. Para una app de admin —formularios, tablas, ajustes— este modelo encaja como un guante y elimina la mitad de la complejidad de un SPA clásico con su capa de fetching.
3. Lenguaje y UI: TypeScript, React 18, Polaris 13 y App Bridge 4
3.1 TypeScript sin discusión
Todo el proyecto es TypeScript (React 18 con TSX). En una app de Shopify el tipado fuerte paga doble: por un lado el clásico ahorro de errores en refactors; por otro, la Admin API de GraphQL tiene un esquema enorme y versionado trimestralmente, y con GraphQL codegen configurado (un fichero .graphqlrc.ts en la raíz) cada query y mutation que escribes genera automáticamente sus tipos. Autocompletado real contra el esquema de la versión de API que usas, y errores de compilación cuando Shopify depreca un campo. Es de esas piezas de tooling que cuestan una hora montar y ahorran semanas.
3.2 Polaris y App Bridge: no reinventes el admin
Polaris 13 es el sistema de diseño de Shopify: componentes React que replican exactamente la apariencia del admin. App Bridge 4 es el puente con el admin que envuelve tu app: navegación, toasts, modales nativos, barra de guardado contextual. La combinación hace que tu app se sienta parte de Shopify y no un iframe extraño — y además la coherencia visual con el admin es uno de los criterios que Shopify valora al homologar apps para su App Store.
Una lección de nuestro último proyecto, contada con honestidad: parte de la UI se construyó con CSS-in-JS propio imitando el aspecto de Polaris en lugar de usar los componentes. Funciona y a corto plazo da más control fino, pero genera una deuda silenciosa: cada actualización visual del admin (y Shopify las hace) desalinea tu imitación, y pierdes gratis la accesibilidad y el pulido de los componentes oficiales. Nuestra recomendación tras la experiencia es clara: Polaris para todo lo que sea posible, CSS propio solo donde Polaris no llega de verdad.
4. La capa de datos: Prisma 6 y la decisión SQLite / PostgreSQL / MariaDB
El template trae Prisma (nosotros en la versión 6) como ORM, inicialmente para persistir las sesiones OAuth, y es natural extenderlo a tus propias tablas: configuración por tienda, logs de sincronización, colas de trabajo, lo que tu dominio necesite. El esquema declarativo, las migraciones con prisma migrate y el cliente tipado encajan perfectamente con el resto del stack TypeScript.
La decisión interesante no es el ORM sino el motor. Y aquí la respuesta correcta cambia según el momento del proyecto:
4.1 SQLite para desarrollo (y solo para desarrollo)
El template arranca con SQLite: un fichero local, cero configuración, funciona en cualquier máquina del equipo desde el minuto uno. Para desarrollo y prototipos es imbatible y no hay razón para complicarse antes. Sus límites llegan con la producción real: escrituras concurrentes serializadas, un solo fichero que ata la app a una única instancia (adiós a escalar horizontalmente o a desplegar en plataformas efímeras) y backups artesanales. Para una app que recibe webhooks en ráfagas, es un cuello de botella anunciado.
4.2 PostgreSQL como opción por defecto en producción
Cuando la app sale de dev hacia PRE y producción, nuestra opción por defecto es PostgreSQL: concurrencia excelente, tipos JSON/JSONB de primera (muy útiles para guardar payloads de Shopify sin esquematizar cada campo), y servicio gestionado disponible en cualquier proveedor (RDS, Cloud SQL, Neon, Supabase, un Postgres en tu propio VPS). El ecosistema Prisma lo trata como ciudadano de primera y la migración desde SQLite es casi solo cambiar el datasource y regenerar migraciones.
4.3 MariaDB/MySQL cuando el contexto lo pide
MariaDB (o MySQL) es la alternativa perfectamente digna: replicación madura, rendimiento sólido en lecturas y una ventaja práctica que en pymes pesa mucho — infraestructura y conocimientos ya existentes. Si tu equipo lleva años operando MariaDB para el resto de sistemas, forzar Postgres solo por moda es mal trade-off; Prisma soporta ambos con la misma API. Nuestro criterio: PostgreSQL si partes de cero, MariaDB si tu operación ya vive en ese mundo. Lo único no negociable es salir de SQLite antes de producción.
5. Tooling: Vite, pnpm y la disciplina del proyecto
El template usa Vite como build tool y dev server, y se nota: arranque instantáneo, HMR fiable y una configuración que casi nunca hay que tocar. Como gestor de paquetes usamos pnpm — más rápido y más estricto que npm con las dependencias fantasma, algo que se agradece en un monorepo o cuando la app crece. ESLint y Prettier completan la disciplina básica; en equipo, con CI que bloquee lo que no pasa lint, no como sugerencia.
La pieza menos conocida y más valiosa ya la hemos mencionado: GraphQL codegen conectado al esquema de la Admin API. Junto con el Shopify CLI (que gestiona el túnel de desarrollo, la instalación en la tienda de pruebas y el deploy de extensiones), forma el circuito de feedback rápido que hace agradable desarrollar contra Shopify en 2026.
6. Las librerías que acaban entrando: zod y p-limit
Hay dos incorporaciones de nuestro último desarrollo que ya consideramos parte del stack estándar para cualquier app de Shopify seria.
zod, para validación en runtime. TypeScript valida en compilación, pero todo lo que entra por la frontera —payloads de webhooks, respuestas de la API, formularios, variables de entorno— llega en runtime sin garantías. Definir esquemas zod para cada payload externo convierte errores silenciosos de datos («este pedido viene sin el campo que esperaba») en fallos explícitos y trazables. En una app que reacciona a webhooks de pedidos, es la diferencia entre un bug detectado en minutos y datos corruptos descubiertos semanas después. Es el mismo principio de defensa de frontera que aplicamos en seguridad de APIs: validar todo lo que entra.
p-limit, para controlar concurrencia. La Admin API de Shopify tiene rate limits basados en coste de query, y cualquier proceso masivo —sincronizar el catálogo, reprocesar pedidos históricos, recorrer clientes— que lance peticiones sin control acabará estrangulado con errores 429. Envolver las llamadas en un limitador de concurrencia (y respetar el coste disponible que la propia API reporta en cada respuesta) convierte un proceso frágil en uno predecible. Para volúmenes realmente grandes, el paso siguiente son las bulk operations de GraphQL, pero p-limit cubre con elegancia el 90% de los casos.
7. De desarrollo a producción: lo que el template no decide por ti
El template te deja a las puertas de producción, pero el último tramo es tuyo. Las decisiones que tuvimos que tomar (y que tendrás que tomar): dónde desplegar el servidor Node —cualquier plataforma con soporte de contenedores o Node persistente sirve: Fly.io, Render, Cloud Run, un VPS bien gestionado—, la base de datos gestionada (sección 4), la gestión de secretos (API keys y tokens fuera del repo, rotables), y observabilidad mínima: logs estructurados y alertas sobre los fallos de webhooks, que son el síntoma temprano clásico de que algo va mal.
Dos consejos de guerra. Primero, procesa los webhooks de forma asíncrona: responde 200 rápido, encola el trabajo (una tabla de jobs en tu propia BD gestionada con Prisma es suficiente al principio) y procesa después; Shopify reintenta los webhooks que fallan, pero un endpoint lento acaba marcándote como app problemática. Segundo, versiona conscientemente la API: Shopify publica versión trimestral y depreca con calendario público; fija la versión en el código, lee los changelogs y planifica una actualización por trimestre como tarea de mantenimiento normal, no como emergencia. Este tipo de evolución continua —la misma que obligó a migrar de Scripts a Shopify Functions antes de su deadline— es la constante del ecosistema.
7.1 Entornos y flujo de trabajo en equipo
Un detalle operativo que el template tampoco resuelve: la separación de entornos. En Shopify cada entorno de tu app es, en la práctica, una app distinta en el Partner Dashboard — una para desarrollo (instalada en tiendas de desarrollo), otra para PRE y la definitiva de producción, cada una con sus credenciales, sus URLs de callback y su base de datos. Mantener esta separación desde el principio evita el clásico accidente de probar una migración destructiva contra datos reales. En equipo, el flujo que nos funciona: ramas cortas con revisión obligatoria, CI que ejecuta lint, tipos y tests en cada push, migraciones de Prisma aplicadas automáticamente al desplegar en PRE y de forma supervisada en producción. Con tiendas de desarrollo gratuitas e ilimitadas para partners, no hay excusa para no tener un entorno de pruebas realista donde reproducir escenarios de merchant reales antes de tocar producción.
8. Errores comunes al empezar (los hemos visto todos)
Partir de cero en lugar del template oficial, normalmente por preferencia previa por otro framework: acabas reimplementando OAuth y session tokens mal. Quedarse en REST por comodidad: la inversión en GraphQL se amortiza el primer mes. Imitar Polaris con CSS propio (ya confesado arriba). Llegar a producción con SQLite «porque funciona». Procesar webhooks en línea y descubrir los timeouts con la primera campaña fuerte del merchant — si tu app toca pedidos, el rendimiento de la tienda y el de tu app se mezclan a ojos del cliente. Y el error de producto, no de código: construir la app sin decidir desde el inicio si será custom (para un solo merchant) o pública, porque esa decisión cambia requisitos de seguridad, facturación y revisión — los analizamos en detalle en nuestra guía para publicar y homologar tu app en la Shopify App Store.
¿Necesitas desarrollar o mantener una app de Shopify?
En Keliam desarrollamos apps embebidas de Shopify con el stack oficial (React Router, Polaris, Prisma) y nos encargamos de su evolución: actualizaciones de API, nuevas funcionalidades y soporte continuo.
Conclusión
El stack para desarrollar una app de Shopify en 2026 tiene una virtud rara: está prácticamente decidido, y bien decidido. TypeScript con React 18, el template oficial de React Router v7 como sucesor de Remix, Polaris 13 con App Bridge 4 para una UI indistinguible del admin, Prisma 6 sobre SQLite en desarrollo y PostgreSQL o MariaDB en producción, Vite y pnpm como tooling, y zod más p-limit como acompañantes que tarde o temprano acabarás agradeciendo. La energía que no gastas eligiendo framework la inviertes donde de verdad se gana el proyecto: en modelar bien el dominio del merchant, tratar los webhooks con el respeto que merecen y mantener la app al ritmo trimestral que marca Shopify. Si además la app aspira a la App Store pública, la homologación añade su propia lista de requisitos: los tienes desgranados en nuestra guía de publicación y homologación en la App Store.
Preguntas frecuentes
¿Sigue siendo válido el template de Remix?
Las apps existentes sobre el template de Remix siguen funcionando y Shopify ha documentado la ruta de migración, pero para proyectos nuevos el punto de partida es el template de React Router v7 (@shopify/shopify-app-react-router). Al ser React Router v7 la continuación de Remix, la migración es incremental y los conceptos (loaders, actions) son los mismos.
¿Puedo usar otro framework como Next.js o un backend PHP/Laravel?
Poder, puedes: Shopify publica librerías de API para varios lenguajes y una app es al final una web con OAuth. Pero quedas fuera del camino mantenido por Shopify: más código de integración propio, menos ejemplos, y actualizaciones de plataforma que te llegan tarde. Salvo restricción fuerte de equipo, el template oficial es la opción racional.
¿Cuándo migrar de SQLite a la base de datos definitiva?
Antes del primer entorno compartido (PRE/staging). Cuanto más tarde migres, más datos y más fricción; el cambio con Prisma es barato al principio (cambiar el datasource y regenerar migraciones) y se encarece con cada tabla nueva. En cuanto haya más de un desarrollador o una instancia desplegada, SQLite ya está de prestado.
