Regra fica no servidor
Tudo que chega do navegador é sugestão, não verdade. Preço, permissão e dono do dado se decidem no servidor ou no banco. Foi assim que fechei a adulteração de preço na loja e a escalada de administrador na agenda.
Disponível para vaga júnior
Sou o Nelson, estudante de Engenharia de Software no primeiro ano, em Santa Maria/RS. Hoje tenho contato mais direto com Python na graduação e evoluo construindo projetos com JavaScript, Node.js, bancos de dados, Flutter, C++, APIs e integrações.
Antes de programar, eu trabalhava com vendas — e via de perto o tanto de tempo que se perde com planilha bagunçada, visita anotada no papel e conta de lucro feita na calculadora do celular. Eu não fui procurar um problema pra resolver: eu já vivia dentro dele.
O primeiro sistema que fiz foi pra mim mesmo. Depois virou coisa que outras pessoas usam de verdade — uma equipe de corretores marca as visitas do dia numa agenda que eu escrevi, e um revendedor controla estoque e fiado num aplicativo que eu publiquei.
É aí que o back-end deixou de ser matéria de faculdade e virou responsabilidade. Quando o dado é de outra pessoa, você para de perguntar "funciona?" e passa a perguntar "o que acontece se alguém tentar burlar isso?" — essa pergunta é a que mais me ensinou até hoje, e é o tipo de dev que eu quero ser num time.
Do site de um cliente no ar ao código aberto de cada um. Passe o mouse e clique — abre o site, o repositório ou o app rodando.
Site de um cirurgião em Santa Maria, no ar em domínio próprio. Cliente real: layout responsivo, seções de especialidades e cirurgia robótica, e agendamento que cai direto no WhatsApp do consultório. Feito pra carregar rápido e passar confiança já na primeira dobra.
O erro clássico de loja mal feita é confiar no preço que o navegador manda. Aqui o carrinho envia só o produto e a quantidade — o total é somado a partir do preço do banco. Senha em bcrypt, sessão por JWT, limite de tentativas no login, e o servidor se recusa a subir com segredo fraco.
API REST que dá contas e sincronização entre aparelhos ao CRM. Cada lead pertence a um usuário, e a rota confere o dono antes de responder — sem isso, trocar o número na URL entregaria o cliente do vizinho. Sete endpoints, autenticação por token e deploy descrito em arquivo.
Kanban de leads que abre e funciona, sem cadastro: os dados ficam no navegador. Quando a pessoa cria uma conta, passam a sincronizar na nuvem. Se o servidor cair ou a sessão expirar, o app volta sozinho pro modo local sem perder nada — degradar bem é parte do projeto.
Agenda de visitas de uma equipe de corretores, em uso. Como o navegador fala direto com o banco, toda a autorização vive dentro do PostgreSQL — o JavaScript o usuário consegue alterar, o banco não. Escrevi um gatilho que impede alguém de mudar o próprio cargo e virar administrador.
Gestão para revendedor: lucro por venda, estoque, fiado e caixa. O aplicativo mobile permanece separado e sem alterações; aqui o link abre somente a versão web disponível hoje.
Sistema de agendamento para clientes e equipe, com cadastro, login, horários, reservas e painel administrativo. O projeto combina front-end React com autenticação, API e banco PostgreSQL.
Commit por commit, incluindo os erros e as correções. Se você é dev e quer avaliar o que eu realmente sei, é o lugar mais honesto pra olhar — melhor do que qualquer coisa escrita nesta página.
Não é lista de qualidade pra entrevista. É o que aparece no código, e dá pra conferir.
Tudo que chega do navegador é sugestão, não verdade. Preço, permissão e dono do dado se decidem no servidor ou no banco. Foi assim que fechei a adulteração de preço na loja e a escalada de administrador na agenda.
Servidor fora do ar não pode virar tela branca. O CRM detecta a queda e volta pro modo local sem perder lead; a sessão expirada avisa e continua funcionando. Quem vai usar não tem que entender o que quebrou.
Meus README explicam a decisão, não só o comando de instalar. Comentário no código diz por quê, nunca o quê. Um dia esse "alguém depois" vai ser um colega de time — ou eu mesmo, seis meses na frente.
Graduação em curso. É de onde vem a base de estrutura de dados, arquitetura e banco relacional.
Formação em andamento, complementando a base em desenvolvimento, modelagem e processo de software.
Banco de Dados no Instituto Federal / Aprenda Mais e uma seleção de certificados da DIO em Python, Node.js, SQL, dados e desenvolvimento.
Na faculdade, meu foco atual é Python e lógica de programação. Em projetos próprios, estudo APIs e integrações, banco de dados, JavaScript/Node.js e C++ com Unreal Engine.
Formação contínua na DIO — com foco aqui nas trilhas mais ligadas ao que estou estudando e construindo hoje.
A trilha completa, do primeiro passo aos arquivos e coleções.
Fundamentos do ambiente onde eu construo minhas APIs.
Banco relacional, ETL e análise — a base dos projetos.
Cursos e desafios de carreira, projetos e análise de dados.
Recrutador, gestor de time ou dev — deixe seu contato que eu retorno. Se preferir, os canais diretos estão ao lado.