Estudo de caso · Fábrica de Software do Unipê
Sistema de gestão acadêmica que ajudei a construir nas três camadas — banco, API e interface — e a colocar em produção.
01 /
O projeto de extensão Administração para Todos oferece cursos à comunidade e controlava matrícula, frequência e certificados sem um sistema.
Eram três públicos com necessidades diferentes: a coordenação precisava de indicadores e relatórios; os instrutores, de chamada, cronograma e materiais; os alunos, de acompanhar o próprio progresso e baixar o certificado.
02 /
Minha parte: o banco, a autenticação, o backend e a integração da área do coordenador, o dashboard do instrutor e a preparação para produção.
03 /
O front-end em Next.js fala com uma API em Express organizada em arquitetura limpa. O caso de uso depende da interface AuthRepository, não do Postgres: a implementação concreta, PostgresAuthRepository, mora na camada de infraestrutura.
Na prática, trocar o banco seria escrever outro repositório — a regra de negócio não mudaria. O preço é mais arquivos e mais cerimônia; o ganho aparece nos testes: os casos de uso rodam com repositórios falsos (jest.Mocked<AuthRepository>), sem subir banco.
04 /
usuarios centraliza a autenticação e cada perfil guarda só o que é dele. O status do curso não é coluna: ele é calculado a partir das turmas a cada consulta, para não existirem duas fontes da verdade.
Em 18/09 removi duas tabelas que nenhuma linha de código lia ou escrevia. Uma delas guardaria documento pessoal de aluno — tirar tabela vazia também é minimização de dados, não só faxina.
05 /
Ganho
O aluno entra com o dado que lembra, sem precisar escolher o tipo de login.
A busca precisa normalizar o CPF, tirando pontos e traços. Foi exatamente essa normalização que criou o bug descrito na próxima seção.
Ganho
Cada requisição carrega um token assinado, guardado em cookie httpOnly pela rota do Next. O backend não precisa consultar sessão.
O logout apaga o cookie, não o token: um token assinado vale até expirar, e a validade fica em 8 horas.
Ganho
O login passa pela rota do Next, então o backend enxerga o mesmo IP para todo mundo. Limitar por IP travaria o sistema inteiro depois de algumas senhas erradas somadas.
Limitar também por IP exige confiar no IP repassado pelo proxy, o que só é seguro quando a API aceita conexões apenas dele.
Ganho
A lista de bloqueio guardava CPF, nome e e-mail para sempre, depois da exclusão — a exclusão não excluía. Agora ela responde só “este CPF está bloqueado?”.
HMAC e não SHA-256 puro: CPF tem cerca de 10⁹ valores, e um hash sem segredo cairia por força bruta. O segredo precisa ficar no ambiente do backend e ser o mesmo em toda migração.
06 /
Sintoma
A busca por e-mail ou CPF em buscarUsuarioPorIdentificador podia devolver uma conta diferente da que tentava entrar.
regexp_replace($1, '[^0-9]', ''), vira string vazia.coalesce(a.cpf, '') também vira string vazia.LIMIT 1 devolvia uma qualquer — não necessariamente a dona do e-mail.Correção
Comparar CPF só quando o identificador tem dígitos, e sem o coalesce: CPF nulo não casa com nada.
O que ficou: normalização que transforma entrada inválida em string vazia precisa de guarda. Vazio sempre casa com vazio.
LEFT JOIN coordenadores c ON c.usuario_id = u.id WHERE lower(u.email) = lower()- OR regexp_replace(coalesce(a.cpf, ''), '[^0-9]', '', 'g')- = regexp_replace(, '[^0-9]', '', 'g')+ OR (+ length(regexp_replace(, '[^0-9]', '', 'g')) > 0+ AND regexp_replace(a.cpf, '[^0-9]', '', 'g')+ = regexp_replace(, '[^0-9]', '', 'g')+ ) LIMIT 1fix: busca por identificador podia autenticar o usuário errado
07 /
Conduzi a preparação para produção: auditoria de segurança, adequação à LGPD, remoção de código morto, proteção de credenciais e limpeza dos dados de teste. Os commits abaixo são meus e estão no repositório.
08 /
No fim do ciclo 2026.1, recebi da Fábrica de Software o certificado de destaque Liderança & Produtividade.
