Skip to content

BillRizer/auction-api

Repository files navigation

Auction API

API para leilão de produtos raros

image image Note:

  • A tabela Bid e Sale não possui as FKs de User e Product para simplificar o teste. Para que um Bid seja criado, é verificado se o User e Product existe, para o Sale também, por isso não quebraria a lógica aplicada por um relacionamento na database, e conforme efetuado apenas "SoftDelete" não ficariam registros órfãos.
  • o campo Role não foi implementado.

LIMIT_AUCTION_TIME = Define quanto tempo dura os rounds de cada leilão

AUCTIONEER_FREQUENCY_INTERVAL_MS = frequencia que o modulo que verifica o vencedor atua.

Modules:

Auth:

overview

módulo para autenticação JWT e login

tech

Apenas um módulo comum do NestJs


User

overview

módulo para CRUD de usuarios

tech

Apenas um módulo comum do NestJs


product

overview

módulo para CRUD de produtos e de um usuario

tech

Apenas um módulo comum do NestJs


bid

overview

módulo para Criar e listar lances relativos a um produto

tech

Apenas um módulo comum do NestJs


auctioneer

overview

modulo que verifica leiloes finalizados e define o vencedor. Ao acabar o tempo o modulo "Auctioneer" verifica o ganhador com o maior lance no tempo limite, que tenha crédito suficiente, caso contrario o próximo da lista sera o ganhador, caso nenhum possua crédito ou o produto não tenha lances, será retornado ao estado de um produto não vendido.

tech

Este modulo possui características diferentes de um módulo normal do NestJs, pois ele entra em loop para verificar os leiloes que estão acontecendo. Decidi utilizar o padrão criacional "Singleton", embora viole o princípio de responsabilidade única, permite que mantenha apenas uma instância da classe em todo código, mesmo que chame este modulo em outro lugar, sera mantida a instância, isto previne que o modulo Auctioneer seja criado em outros lugares e assim gerando problemas de concorrência, uma vez que este modulo trabalha em loop.

Note: Uma solução mais rápida e com suporte do framework seria criar uma "Task Schedule" + Redis. A cada produto que for definido como "disponível para leilão" ele agenda a execução do processo que verifica o vencedor. Fiz da forma menos automatizada para demostrar minha capacidade de solucionar problemas.



tests

image

Swagger

http://localhost:3000/api/v1

image

[ * ] /user - CRUD de usuário

[ * ] /product - CRUD de produto

[GET] /product/available-for-auction - produtos que estao atualmente em leilão

[POST] /product/available-for-auction/{product-id} - colocar um produto para leilão (este produto deve ser seu)

[POST] /bid/{product-id} - efetuar um lance para qualquer produto em leilão

[GET] /bid/{product-id} - listar todos os lances para aquele produto (desc pelo valor mais alto)

[GET] /sale/ - listar todos os vencedores, produtos e valores.

TODO

[] Apos o usuário vencer um leilao deve receber um email
[] Testar performance 
[] Melhorar deploy
[] Refatorar mult-stage building
[] Criar automaticamente a database auction_e2e para Dev

Stack

  • NestJS
  • TypeOrm
  • Jest
  • Postgres
  • Swagger
  • Docker
  • Husky
  • Eslint
  • Conventional commits
  • logs

development:

./deploy --dev

before tests, create database auction_e2e for integrations tests tests:

#e2e test
yarn test:e2e:watch

#integrations test
yarn test:int:watch

#unity test
yarn test:watch

production:

#Como utilizo multi-stage-building, é necessario executar o deploy em dev e quando os containers iniciarem, cancelar a execucao, como exemplo abaixo:

./deploy --dev

#Quando iniciar a api, pressione CTRl+C para encerrar a execucão dos containers

./deploy --prod
#A base url é http://localhost:3000/api/v1

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages