Sprint 1: API NestJS em Memória
Modele a fronteira HTTP e o fluxo controller-service-repository antes de introduzir banco de dados.
Materiais: abra o repositório ou baixe o pacote da Sprint 1. Comece por
student-starter/.
História de usuário
Como cliente da API, quero verificar sua saúde e manipular transações por HTTP, para integrar sem conhecer detalhes da implementação.
Crie um projeto NestJS com configuração estrita de TypeScript. Implemente GET /health e o CRUD de /transactions usando um repositório em memória. Nesta sprint, use um identificador fixo de usuário dentro do serviço; autenticação real entra depois.
Arquitetura esperada
src/
health/
transactions/
dto/
domain/
transactions.controller.ts
transactions.service.ts
transactions.repository.ts
in-memory-transactions.repository.tsControllers traduzem HTTP. Services aplicam regras. O repositório guarda e recupera dados. Defina uma interface de repositório para que a próxima sprint troque memória por Prisma sem reescrever controllers.
Critérios de aceite
GET /healthresponde200com{ "status": "ok" }.- Criar responde
201; buscar e editar respondem200; remover responde204. - Identificadores usam UUID.
amountInCentsaceita somente inteiro positivo.- Datas e enums seguem o OpenAPI.
- Recurso ausente responde
404no formato comum de erro. - DTO não aceita propriedades desconhecidas.
Explore todas as rotas com o arquivo .http do kit ou cliente equivalente. O starter contém somente o scaffold e o health check; construa o restante antes de comparar o comportamento com kit/reference-api/.