Una plataforma ecommerce con la que no tienes que pelear

Elige cualquiera de las 10 principales plataformas SaaS de commerce y mira su documentación de API. Después mira su UI de admin. Las funcionalidades no coinciden. El admin puede hacer cosas que la API no puede. Peor aún: el proveedor de la plataforma lo sabe — y considera que es una feature, no un bug. Bloquear capacidades detrás del admin es lo que te mantiene en su plataforma. En el momento en que puedes hacer todo por API, también puedes irte.

Esa es la tensión fundamental. Las grandes plataformas SaaS (Shopify, BigCommerce, Wix Commerce) optimizan para comerciantes no técnicos porque son la mayor parte de su TAM. Cuando los desarrolladores piden un webhook para un evento concreto, una forma de registrar un paso de checkout personalizado, o acceso de escritura a un recurso que antes era solo lectura, la respuesta suele ser «sube al tier enterprise» o «usa Zapier».

Axnify está construida de forma diferente porque su backend está estructurado para ello. Cada dominio es un microservicio (product, order, cart, theme, billing, asset, customer, payment, shipping, etc.) con su propio esquema de base de datos y su propia API HTTP. La UI de admin es un frontend que habla con esas APIs — exactamente igual que tu código. No hay capacidades solo-admin. No hay «endpoint interno» que no puedas llamar. La superficie de la API ES la plataforma.

Esa decisión de diseño tiene consecuencias. Significa que Axnify es más honesta sobre lo que soporta y lo que no: si no está en la API, no existe. Significa que los breaking changes se detectan antes — no puedes lanzar una feature de admin sin lanzar también la API. Y significa que tú, como desarrollador integrando contra la plataforma, nunca estás en la posición de escribir un screen-scraper porque el admin pueda hacer algo que tu código no puede.

La arquitectura clásica de plataforma ecommerce — Shopify, Magento, WooCommerce — es una única codebase monolítica corriendo contra una única base de datos. Eso hace la plataforma rápida de construir al principio y fácil de razonar para tiendas pequeñas. También significa que cada feature comparte el mismo runtime, el mismo pool de conexiones a la base de datos y el mismo ciclo de release. Cuando el equipo de plataforma lanza una nueva feature, cada comerciante la obtiene (o el bug que viene con ella) el mismo día.

Axnify toma el enfoque opuesto. Cada dominio de commerce vive en su propio microservicio Go. El servicio product es dueño de productos, variantes, opciones e inventario. El servicio order es dueño de pedidos, líneas y fulfillments. El servicio cart es dueño de los carritos activos. El servicio asset es dueño del almacenamiento de ficheros. El servicio theme es dueño de temas, páginas, sections y bloques. En total hay más de 20 servicios así, cada uno con su propio esquema PostgreSQL, su propio directorio de migraciones, sus propios tests, cada uno desplegable independientemente.

Los servicios se comunican sobre HTTP usando autenticación con clave interna para llamadas service-a-service y JWT/X-Tenant-ID para llamadas originadas por usuario final. Las preocupaciones compartidas (auth, resolución de tenant, rate limiting, logging, métricas, error tracking) viven en un paquete middleware compartido que cada servicio importa. PostgreSQL es compartido pero los esquemas están aislados; un servicio puede hacer JOIN contra las tablas de otro vía vistas, pero las escrituras pasan por la API del servicio dueño.

Para ti como desarrollador que integra contra la plataforma, esta arquitectura tiene implicaciones prácticas. Las APIs son estables por servicio: la API product evoluciona a su propio ritmo, la API order al suyo. Los webhooks vienen del servicio dueño del evento, con metadatos ricos sobre qué servicio emitió qué. El rendimiento está acotado por dominio: una consulta de reporte lenta en el servicio de analytics no puede bloquear tu llamada de order-create. Y el debugging es más fácil porque cada request lleva un request ID que se loggea en cada servicio que toca.