Este projeto é uma API desenvolvida para processar e expor estatísticas e rankings de partidas de Quake com base em arquivos de log. Ele foi criado como parte de um exercício técnico para uma vaga de backend.
Essa API processa logs de partidas do jogo Quake para gerar estatísticas de jogo e rankings de jogadores, conforme as seguintes histórias de usuário:
- História 1: Estatísticas por jogo: total de mortes, mortes por causa e mortes causadas pelo
<world>. - História 2: Ranking dos jogadores de cada partida com pontuação baseada em kills e mortes pelo mundo.
- História 3: Consulta das estatísticas de jogos específicos ou de todos os jogos via API para visualização.
- Linguagem: TypeScript
- Framework: ExpressJS
- Banco de Dados: Redis (para armazenamento em cache/dados de jogos)
- Documentação API: Swagger em
/api-docs - Containerização: Docker + Docker Compose com Redis e Node.js
src/
├── Application/ # Serviços, DTOs, Mappers e UseCases
├── Domain/ # Modelos, Enums e Interfaces do domínio
├── Incoming/ # Configurações, Controllers e Rotas HTTP
├── Infrastructure/ # Configuração do Redis, Logger e Repositórios
├── index.ts # Ponto de entrada da aplicação
Exercício: Quake Log Parser
- Suba a aplicação com:
docker-compose up --build-
Acesse:
- API:
http://localhost:3000 - Swagger:
http://localhost:3000/api-docs
- API:
- Instale dependências:
npm install- Inicie o servidor:
npm run devCertifique-se de que o Redis esteja rodando localmente na porta
6379.
Ou use os endpoints diretamente:
| Método | Endpoint | Descrição |
|---|---|---|
| GET | /api/admin/log/game |
Estatísticas de todos os jogos |
| GET | /api/admin/log/game/:gameId |
Estatísticas de um jogo por ID |
| GET | /api/player/rank/games |
Ranking dos jogadores |
- Criar o parser de logs exigiu atenção aos detalhes da formatação das strings.
- Garantir a persistência de dados com Redis e manter estrutura limpa foi desafiador com o tempo limitado.
-
Esse foi um exercício bastante interessante, pois exigiu não apenas codificação, mas também pensamento arquitetural. Tive liberdade para aplicar boas práticas de desenvolvimento, como a separação clara de camadas (Domain, Application, Infrastructure), uso de interfaces, mappers e DTOs. Seguindo princípios da Clean Architecture.
-
Como desenvolvedor experiente, compreendo os riscos de adicionar dependências desnecessárias ou utilizar frameworks mais recentes apenas por conveniência. Embora conheça diversas ferramentas modernas como NestJS, prefiro evitar dependências que possam comprometer a manutenção ou estabilidade do projeto, especialmente em soluções que precisam ser simples, claras e confiáveis.
Gostei bastante da proposta! Foi uma ótima oportunidade para aplicar princípios que valorizo: código limpo, arquitetura bem definida, versionamento, logging estruturado e documentação clara.
Se tivesse mais tempo, com certeza teria incluído testes unitários mais robustos e até um painel web (com Next.js ou outras tecnologias que domino) para visualização gráfica em tempo real dos rankings por partida.