E-commerce do Agro

CONTEXTO

Un negocio del agro necesitaba mucho más que una tienda: ventas, pagos, entregas y gestión por rol.

QUÉ SE HIZO

Plataforma con tienda, checkout con pago, 5 paneles por rol, app de entregas y API documentada, cubriendo del pedido a la entrega.

5 PANELES POR ROL · API DOCUMENTADA

SOLUCIONES

• Capas sin ORM

  Ruta → controller → service → repository con SQL raw vía mysql2; Sequelize solo corre migrations por CLI.

• 4 contextos de auth

  Admin, tienda, corredora y productor con cookie HttpOnly propia, coexistiendo en el mismo navegador, con impersonación.

• Firma digital vía API

  Contratos cerrados por ClickSign v3, webhook validado por HMAC, provider intercambiable por variable de entorno.

• Marketplace B2B integrado

  Módulo Mercado do Café con RBAC de 4 roles por corredora y planes SaaS cobrados vía Asaas.

DETALLE TÉCNICO

• 01El proyecto está dividido en dos repositorios (frontend y backend) que solo se hablan por HTTP, sin import cruzado ni paquete compartido. El…+

  El proyecto está dividido en dos repositorios (frontend y backend) que solo se hablan por HTTP, sin import cruzado ni paquete compartido. El backend es una API REST en Node.js/Express con arquitectura en capas estricta: ruta delgada, controller, service y repository, sin excepción. El acceso a datos usa mysql2 con pool raw, y Sequelize está en el proyecto exclusivamente para correr migrations vía CLI (db:migrate, db:status). No existe un solo Model.findAll() en el código de aplicación: es SQL directo por decisión consciente de proyecto, documentada en el propio README para no confundir a quien llegue después. Toda respuesta HTTP pasa por un contrato único ({ ok, data, code, message, meta }) y todo error esperado se convierte en un AppError capturado por un handler global, nunca res.json() crudo ni res.status(4xx) inline.

• 02El dominio va mucho más allá de carrito y checkout. Existen cuatro contextos de autenticación totalmente independientes, cada uno con cookie…+

  El dominio va mucho más allá de carrito y checkout. Existen cuatro contextos de autenticación totalmente independientes, cada uno con cookie HttpOnly, middleware y endpoint de login propios: admin, cliente de la tienda, corredora de café y productor rural. Los cuatro coexisten en el mismo navegador, así que un admin puede entrar en modo impersonación en el panel de una corredora sin perder su propia sesión. El productor ni siquiera usa contraseña: entra por magic-link con token firmado por HMAC y TTL corto, un flujo pensado para un público rural con baja familiaridad digital. Por encima de la tienda tradicional (productos, drones, carrito, checkout con Mercado Pago) existe un módulo B2B entero, el "Mercado do Café", con RBAC interno de cuatro roles en la corredora (owner/manager/sales/viewer), planes SaaS cobrados vía Asaas y protección anti-bot (Turnstile) en los formularios públicos de captación de leads.

• 03Los contratos entre corredora y productor se cierran con firma electrónica de verdad: integración con la API v3 de ClickSign, webhook valida…+

  Los contratos entre corredora y productor se cierran con firma electrónica de verdad: integración con la API v3 de ClickSign, webhook validado por HMAC secret y un provider intercambiable por variable de entorno (CONTRATO_SIGNER_PROVIDER=stub en staging, clicksign en producción). Es un cambio en un solo lugar, sin stub esparcido por el código. La seguridad tiene peso real en el backend: CSRF vía double-submit cookie, rate limiting adaptativo con Redis y fallback in-memory por si Redis se cae, y un orden de middlewares en server.js deliberadamente no obvio. Helmet define Cross-Origin-Resource-Policy: same-origin por defecto, y el override para servir medios cross-origin en /uploads tiene que venir después de él; si no, los assets simplemente dejan de cargar en otro dominio.

• 04En el frontend, Next.js 15 (App Router) separa la búsqueda de datos pública en fetchers server-only bajo src/server/data/ (RSC, cache: no-st…+

  En el frontend, Next.js 15 (App Router) separa la búsqueda de datos pública en fetchers server-only bajo src/server/data/ (RSC, cache: no-store) de todo lo que es sesión de usuario, resuelto en Client Components vía un apiClient propio que reemplazó Axios por completo. Inyecta el header x-csrf-token automáticamente en mutaciones y centraliza errores como ApiError tipado. Las subidas de medios pasan por un mediaService único en el backend que abstrae disco local, S3 y GCS por variable de entorno, y el frontend nunca arma una URL de imagen a mano: siempre va por absUrl(), que normaliza los formatos de path que el backend puede devolver. Los tests cubren los dos lados (Jest y Supertest en el backend con base de datos de prueba dedicada; Vitest y Testing Library en el frontend). El proyecto es asumidamente un prototipo de estudio y no corre en producción para un cliente real, pero fue construido con la disciplina de arquitectura de un sistema que necesitaría escalar a varias corredoras y regiones productoras de verdad.

RESULTADO

Plataforma con tienda, checkout con pago, 5 paneles por rol, app de entregas y API documentada, cubriendo del pedido a la entrega.

Es solo un prototipo que hice para probar y afinar mis habilidades. No es un producto de cliente.

QUIERO ALGO PARECIDO ↗