E-commerce do Agro

- ESTÚDIO
- MILWEB
- TIPO
- PRODUTO DIGITAL
- STATUS
- PROTÓTIPO DE ESTUDO
02 / A IDEIA
Sistema web completo · e-commerce + painéis
Um negócio do agro precisava de muito mais que uma loja: vendas, pagamentos, entregas e gestão por papel.
01 / 01
Rota → controller → service → repository com SQL raw via mysql2; Sequelize só roda migrations por CLI.

02 / 02
Admin, loja, corretora e produtor com cookie HttpOnly próprio, coexistindo no mesmo navegador, com impersonação.

03 / 03
Contratos fechados pela ClickSign v3, webhook validado por HMAC, provider trocável por variável de ambiente.

04 / 04
Módulo Mercado do Café com RBAC de 4 papéis por corretora e planos SaaS cobrados via Asaas.

01
02
03
04
04 / POR BAIXO DO CAPÔ
01O projeto é dividido em dois repositórios (frontend e backend) que só se falam por HTTP, sem import cruzado nem pacote compartilhado. O back…+
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.
02O domínio vai muito além de carrinho e checkout. Existem quatro contextos de autenticação totalmente independentes, cada um com cookie HttpO…+
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.
03Contratos entre corretora e produtor são fechados com assinatura eletrônica de verdade: integração com a API v3 da ClickSign, webhook valida…+
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.
04No 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 tu…+
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.
CONSTRUÍDO COM — Next.js · Node.js · Express · MySQL · DockerCÓDIGO ↗CÓDIGO ↗
06 / RESULTADO
Akatsuki
