MILWEB®
MILWEB®
MW/026E-COMMERCE DO AGROESTÚDIO

E-commerce do Agro

E-commerce do Agro — tela inicial
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.

03 / EXPERIÊNCIA
  1. 01 / 01

    Rota → controller → service → repository com SQL raw via mysql2; Sequelize só roda migrations por CLI.

    E-commerce do Agro — 01
  2. 02 / 02

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

    E-commerce do Agro — 02
  3. 03 / 03

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

    E-commerce do Agro — 03
  4. 04 / 04

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

    E-commerce do Agro — 04
Sistema web completo · e-commerce + painéis

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 COMNext.js · Node.js · Express · MySQL · DockerCÓDIGOCÓDIGO

06 / RESULTADO

5 painéis por papel · API documentada

PROTÓTIPO DE ESTUDO

[ QUERO ALGO PARECIDO ]

PRÓXIMA EXPERIÊNCIA20 / AKATSUKI

Akatsuki

Akatsuki

TODOS OS PROJETOS

TODOS OS PROJETOS