Como foi construído
Todo o desenvolvimento deste projeto seguiu um processo estruturado, documentado publicamente no próprio
repositório: cada funcionalidade nasce de uma etapa de brainstorm, é formalizada em um documento de design
(spec) e um plano de implementação detalhado, e só então é implementada - tarefa por tarefa, com revisão de
código dedicada após cada uma e uma revisão final abrangendo o conjunto completo de mudanças antes de
qualquer código chegar à branch principal.
A implementação do código é assistida por inteligência artificial (Claude Code), mas as decisões que
definem a qualidade de um sistema - modelagem de dados, escolha de ferramentas e frameworks, arquitetura de
segurança, revisão de schema de banco de dados - são meu papel neste processo. A IA implementa sob um
processo de revisão rigoroso que eu defini, e os dois casos abaixo mostram, na prática, decisões corretas
sendo tomadas por causa desse processo, não apesar dele.
Caso real: rota pública que
derrubaria a produção
Ao adicionar uma nova rota pública ao proxy reverso (Traefik), o arquivo de configuração passou a ter
dois serviços definidos no mesmo contêiner sem que cada roteador apontasse explicitamente para o serviço
correto. Esse é um comportamento documentado do provedor Docker do Traefik: com mais de um serviço no
mesmo contêiner, ele não consegue associar automaticamente um roteador a um serviço - e descarta os
dois roteadores. Isso quebraria não apenas a rota nova, mas também uma rota que já estava em produção. O
problema foi identificado em uma revisão de segurança dedicada especificamente a essa mudança, verificado
de forma independente contra a documentação oficial do Traefik antes de ser confirmado, e a correção foi
validada por uma nova revisão isolada, focada só nesse ajuste.
Caso real: um bug que só a revisão de
sistema completo encontraria
O endpoint que calcula os perks mais bem e mais mal avaliados pela comunidade selecionava as duas listas
a partir do mesmo conjunto de dados ordenado, sem excluir de uma lista os itens já presentes na outra.
Com poucos votos registrados - o cenário real esperado logo após o lançamento -, o mesmo item podia
aparecer ao mesmo tempo como o mais bem avaliado e o mais mal avaliado. Isolado, o código de cada tarefa
individual estava correto; o problema só ficou visível na revisão final, que avalia o sistema como um
todo, não arquivo por arquivo. Foi corrigido e coberto por um teste automatizado que garante que isso
não volte a acontecer.
Arquitetura e stack
O sistema é composto por um bot para Discord (discord.py), uma API em FastAPI, banco de dados PostgreSQL
com SQLAlchemy, um script de sincronização contra a API pública da Bungie, e uma pipeline de deploy
automatizado via Docker Compose e GitHub Actions, publicada em uma VPS atrás de um proxy reverso Traefik
com certificados HTTPS emitidos automaticamente (Let's Encrypt).
Banco de dados próprio, não dependência direta
da API
O bot e a API nunca consultam a API da Bungie diretamente durante uma requisição de usuário. Um script de
sincronização roda periodicamente, busca os dados públicos da Bungie e os grava em um banco PostgreSQL
próprio - todo o tráfego de usuário é servido a partir desse banco, nunca da API externa em tempo real.
Essa escolha significa que a aplicação continua funcionando normalmente mesmo quando a API da Bungie está
fora do ar, em manutenção programada ou instável, o que acontece com alguma frequência na prática. É uma
decisão deliberada de disponibilidade, não uma otimização de performance incidental.
Por que Clarity, e não as alternativas óbvias
As descrições detalhadas de cada perk de arma não vêm de nenhuma API oficial da Bungie. Antes de adotar o
dataset comunitário Clarity, avaliei diretamente o destiny.report (aplicação renderizada inteiramente no
cliente, sem API acessível), a planilha pública Data Compendium (exportação em CSV bloqueada por
autenticação) e o light.gg (bloqueia requisições até o próprio robots.txt). A decisão não foi por
suposição - cada alternativa foi testada e descartada por um motivo verificável.
Reaproveitar infraestrutura em vez de
duplicar
O domínio público do projeto usa uma instância do Traefik que já roda na mesma VPS, compartilhada com
outros projetos pessoais, em vez de subir um proxy reverso dedicado. Cada rota exposta publicamente é
declarada de forma explícita e enumerada - nunca um prefixo genérico -, e um teste automatizado falha de
propósito sempre que alguém tenta ampliar essa superfície pública sem atualizar esse teste de forma
consciente.