Acordeavos
Un sistema de ecommerce personalizado que separó la venta al público, las operaciones internas y las reglas de negocio con autoridad en el backend para stock, precios, variantes y dinero.
Desarrollador líder / principal
- Separación entre tienda y administración
- Contrato GraphQL compartido
- Reglas de inventario y precios con autoridad en el backend
Problema
Acordeavos necesitaba un ecommerce en producción para flujos que excedían los de una tienda convencional: gestión de catálogo e inventario, variantes de producto, actualización de stock mediante facturas, precios según el rol, pedidos, reportes, cupones, medios de pago personalizados y operaciones administrativas.
Contexto y responsabilidad
Lideré el desarrollo como desarrollador principal, implementando la solución técnica personalizada y haciendo evolucionar su arquitectura a medida que aumentaba la complejidad del negocio. Mi responsabilidad abarcó tanto la venta al público como los flujos internos utilizados para operar el ecommerce.
Alcance del sistema
- Tienda para clientes en Next.js con requisitos de SEO y SSR
- SPA administrativa en React para flujos operativos
- Catálogo, inventario y actualización de stock mediante facturas
- Variantes y precios según el rol
- Pedidos, totales, cupones y medios de pago personalizados
- Reportes y operaciones administrativas continuas
Arquitectura
El sistema utilizó dos superficies frontend de manera deliberada. Next.js servía la tienda para clientes, donde importaban el SEO, SSR, la visibilidad en buscadores y el rendimiento; React impulsaba una SPA interna optimizada para la velocidad de interacción y el trabajo operativo. Ambas utilizaban Apollo para consumir una API GraphQL ubicada delante de Firebase. Ese límite proporcionó un contrato compartido y centralizó el acceso a datos y las reglas de negocio, sin pretender eliminar todo el acoplamiento con la persistencia.
- Tienda en Next.js
- SPA administrativa en React
- Redux
- Límite compartido con GraphQL y Apollo
- Node.js
- Persistencia en Firebase
Desafío de ingeniería
Una única visión autoritativa del estado del ecommerce
El problema más difícil fue mantener un estado de negocio consistente entre inventario, variantes, actualizaciones de stock mediante facturas, precios según el rol, comportamiento de la tienda y flujos administrativos. Permitir que dos superficies de aplicación calcularan o modificaran de manera independiente dinero, stock, precios, variantes o totales de pedidos generaba un riesgo creciente de estados contradictorios.
Decisiones y fundamentos
Separar las superficies de Tienda y Administración
- Decisión
- Usar Next.js para la tienda orientada al cliente y una SPA separada en React para la administración interna.
- Fundamento
- La tienda necesitaba SEO, SSR, visibilidad en buscadores y rendimiento para clientes, mientras que la aplicación administrativa priorizaba la velocidad de interacción y la experiencia operativa. Cada superficie podía así servir a su audiencia real.
- Compensaciones
- Los modelos y tipos compartidos requerían coordinación, la autenticación debía funcionar entre ambas superficies, los despliegues se volvieron más complejos y la consistencia de comportamiento exigía una alineación deliberada. Las aplicaciones estaban separadas, pero no eran completamente independientes.
Un límite de aplicación GraphQL compartido
- Decisión
- Canalizar ambas aplicaciones frontend a través de la misma API GraphQL, consumida mediante Apollo, con Firebase detrás de ese límite.
- Fundamento
- Un contrato de API compartido reducía el acoplamiento directo de los clientes con Firebase, centralizaba el acceso a datos y las reglas de negocio, y proporcionaba patrones de acceso consistentes para ambas aplicaciones.
- Compensaciones
- El límite agregó un contrato que debía evolucionar junto con ambos clientes y no eliminó todas las formas de acoplamiento. Firebase continuó siendo la capa de persistencia, por lo que no se consideró trivialmente reemplazable.
Invariantes del ecommerce con autoridad en el backend
- Decisión
- Mover detrás de la API compartida los cálculos y las transiciones de estado críticas para dinero, stock, precios, variantes y totales de pedidos.
- Fundamento
- A medida que aumentaba la complejidad operativa, la tienda y la aplicación administrativa debían consumir las mismas decisiones de negocio autoritativas en lugar de interpretar por separado reglas sensibles.
- Compensaciones
- La autoridad central redujo la comodidad en los frontends y exigió una coordinación cuidadosa del contrato de API, pero aclaró la consistencia y la propiedad del estado crítico entre ambas superficies.
Contexto de producción
Acordeavos opera como un ecommerce real con flujos continuos de catálogo, inventario, precios, pedidos, reportes y administración. La asistencia de IA apoyó el trabajo de implementación en una etapa posterior, mientras que la funcionalidad del producto y las reglas de negocio del ecommerce continuaron siendo capacidades de software convencionales.
Resultado e impacto
Se entregaron superficies para clientes y operaciones optimizadas para sus tareas reales, con un límite de aplicación compartido y una autoridad más clara en el backend para las reglas críticas del ecommerce. Esto redujo el riesgo de comportamientos contradictorios de stock, precios, variantes, dinero y pedidos entre flujos.
Tecnologías
- Next.js
- React
- Redux
- GraphQL
- Apollo
- Node.js
- Firebase
Diagrama de arquitectura
Ver el proyecto en funcionamiento
Visitar sitio web