E-commerce do Agro

O projeto é dividido em dois repositórios (frontend e backend) que só se falam por HTTP, sem import cruzado nem pacote compartilhado. O backend é uma API REST em Node.js/Express com arquitetura em camadas estrita: rota magra, controller, service e repository, sem exceção. O acesso a dados usa mysql2 com pool raw, e o Sequelize está no projeto exclusivamente para rodar migrations via CLI (db:migrate, db:status). Não existe um único Model.findAll() no código de aplicação: é SQL direto por decisão consciente de projeto, documentada no próprio README para não confundir quem chegar depois. Toda resposta HTTP passa por um contrato único ({ ok, data, code, message, meta }) e todo erro esperado vira um AppError capturado por um handler global, nunca res.json() cru nem res.status(4xx) inline.

O domínio vai muito além de carrinho e checkout. Existem quatro contextos de autenticação totalmente independentes, cada um com cookie HttpOnly, middleware e endpoint de login próprios: admin, cliente da loja, corretora de café e produtor rural. Os quatro coexistem no mesmo navegador, então um admin pode entrar em modo impersonação no painel de uma corretora sem perder a própria sessão. O produtor nem usa senha: entra por magic-link com token assinado por HMAC e TTL curto, fluxo pensado para um público rural com baixa familiaridade digital. Por cima da loja tradicional (produtos, drones, carrinho, checkout com Mercado Pago) existe um módulo B2B inteiro, o "Mercado do Café", com RBAC interno de quatro papéis na corretora (owner/manager/sales/viewer), planos SaaS cobrados via Asaas e proteção anti-bot (Turnstile) nos formulários públicos de captação de lead.

Contratos entre corretora e produtor são fechados com assinatura eletrônica de verdade: integração com a API v3 da ClickSign, webhook validado por HMAC secret e um provider trocável por variável de ambiente (CONTRATO_SIGNER_PROVIDER=stub em staging, clicksign em produção). É uma troca de um lugar só, sem stub espalhado pelo código. Segurança tem peso real no backend: CSRF via double-submit cookie, rate limiting adaptativo com Redis e fallback in-memory caso o Redis caia, e uma ordem de middlewares em server.js deliberadamente não-óbvia. O Helmet define Cross-Origin-Resource-Policy: same-origin por padrão, e o override para servir mídia cross-origin em /uploads precisa vir depois dele, senão os assets simplesmente param de carregar em outro domínio.

No frontend, Next.js 15 (App Router) separa busca de dados pública em fetchers server-only sob src/server/data/ (RSC, cache: no-store) de tudo que é sessão de usuário, resolvido em Client Components via um apiClient próprio que substituiu o Axios por completo. Ele injeta o header x-csrf-token automaticamente em mutações e centraliza erros como ApiError tipado. Uploads de mídia passam por um mediaService único no backend que abstrai disco local, S3 e GCS por variável de ambiente, e o frontend nunca monta URL de imagem na mão: é sempre via absUrl(), que normaliza os formatos de path que o backend pode devolver. Testes cobrem os dois lados (Jest e Supertest no backend com banco de teste dedicado; Vitest e Testing Library no frontend). O projeto é assumidamente um protótipo de estudo e não roda em produção para um cliente real, mas foi construído com a disciplina de arquitetura de um sistema que precisaria escalar para várias corretoras e regiões produtoras de verdade.