Sprint 1 · #3 — Implementar Carrinho de Compras, Checkout e Pedidos

[KauaN-png]

Resolve a issue #3. Depende da #2 (Catálogo de Produtos).

Alterações realizadas:

• app/checkout.js — Novo módulo com:

  Carrinho (por userId via header X-User-Id)

  • GET /api/cart — Visualizar carrinho (subtotal por item + total)
  • POST /api/cart/add — Adicionar item (valida estoque, incrementa se já existe)
  • PUT /api/cart/update/:itemId — Atualizar quantidade (0 = remove)
  • DELETE /api/cart/remove/:itemId — Remover item

  Checkout

  • POST /api/checkout — Finalizar compra:
    • Valida estoque de todos os itens
    • Simula pagamento com delay 500ms-2s
    • 10% de chance de falha no pagamento
    • Abate estoque dos produtos
    • Limpa carrinho após sucesso

  Pedidos

  • GET /api/orders — Listar pedidos do usuário
  • GET /api/orders/:id — Detalhe do pedido (itens, total, status, datas)
  • PATCH /api/orders/:id/status — Avançar status: pending → confirmed → preparing → shipped → delivered

• app/catalog.js — Incluído (mesmo da Sprint 1 · #2 — Implementar API de Catálogo de Produtos #2) como dependência para validação de estoque

• app/app.js — Montagem dos módulos catalog e checkout sob /api

• .gitignore — Ignora node_modules/

[KauaN-png]

📋 Code Review — PR #12 — Carrinho, Checkout e Pedidos (Issue #3)

✅ Acertos

1. Arquitetura modular excelente — checkout.js é um módulo bem isolado (~350 linhas), com responsabilidade clara e desacoplado do resto da aplicação.
2. Logs estruturados consistentes — Padrão [timestamp] [LEVEL] [Checkout] mensagem alinhado com o módulo de catálogo.
3. Validação robusta em todas as camadas:
   • userId obrigatório via header X-User-Id
   • productId e quantity validados antes de adicionar ao carrinho
   • Estoque verificado antes de adicionar item e antes do checkout
   • Carrinho vazio bloqueia checkout com mensagem clara
4. Fluxo de checkout realista:
   • Valida estoque de todos os itens atomicamente
   • Simula pagamento com 10% de chance de falha (HTTP 402)
   • Abate estoque dos produtos
   • Limpa carrinho após sucesso
   • Cria pedido com histórico de timestamps
5. Máquina de estados de pedido — pending → confirmed → preparing → shipped → delivered, com proteção contra transições inválidas (status final bloqueado).
6. Subtotais e total calculados corretamente — (price * quantity).toFixed(2) com parseFloat.
7. Carrinho por usuário — Escopo isolado por userId, escalável para múltiplos usuários simultâneos.
8. Incremento inteligente — Se o mesmo produto já existe no carrinho, a quantidade é incrementada em vez de duplicar o item.
9. .gitignore incluído — node_modules/ devidamente ignorado neste PR 🎉

⚠️ Warnings

1. setTimeout no checkout é fire-and-forget (linhas 274-276)
   O setTimeout loga "pagamento confirmado" depois que a resposta HTTP já foi enviada (res.status(201).json(...)). O delay de 500ms-2s não tem efeito real do ponto de vista do cliente. Se a intenção é simular processamento, o res.json() deveria estar DENTRO do setTimeout:

   setTimeout(() => {
     log('info', `Pedido #${order.id}: pagamento confirmado`);
     res.status(201).json({ ... });
   }, delay);

2. PATCH /api/orders/:id/status — Escopo global de busca (linhas 318-327)
   O endpoint itera sobre pedidos de todos os usuários para encontrar o pedido, ignorando o userId do header. Um usuário pode potencialmente avançar o status de pedidos de outro usuário. Para um laboratório de observabilidade é aceitável, mas documente essa limitação.

3. catalog.js incluso no diff
   Como o PR Sprint 1 · #2 — Implementar API de Catálogo de Produtos #11 (catálogo) ainda não foi mergeado, este PR inclui o módulo catalog.js inteiro (200 linhas). Após o merge do Sprint 1 · #2 — Implementar API de Catálogo de Produtos #11, este PR precisará de rebase em master para mostrar apenas as mudanças do Sprint 1 · #3 — Implementar Carrinho de Compras, Checkout e Pedidos #3.

💡 Sugestões

1. Extrair ORDER_STATUSES para constantes compartilhadas

   // constants.js
   exports.ORDER_STATUSES = ['pending', 'confirmed', 'preparing', 'shipped', 'delivered'];

   Útil se outros módulos precisarem referenciar os mesmos status.

2. Middleware de userId mais explícito
   O middleware tenta extrair userId de req.body (linha 65), mas requests GET não têm body. Considere separar em middleware apenas para header:

   router.use((req, _res, next) => {
     req.userId = req.headers['x-user-id']
       ? parseInt(req.headers['x-user-id'], 10)
       : null;
     next();
   });

3. Proteção para rotas admin
   POST/PUT/DELETE de produtos e PATCH de status de pedidos não têm autenticação. Para um lab de observabilidade funciona, mas considere pelo menos um header X-Admin-Key para simular controle de acesso.

---

Veredito: ✅ Comentário (self-review) — Código de alta qualidade, sugestões não bloqueantes.

[c4rlosfb]

Merge resolvido manualmente após conflito com #2. Código mergeado no master via commit f7dcda2.