Estudos de caso, notas de sistema e encaixe de vaga organizados na mesma superfície editorial.
Repo público
MailSieve
Uma API enxuta de risco para signup com contrato OpenAPI, fluxo de chaves, rate limits e scripts de verificação de deploy.
Por que este caso importa
MailSieve é um bom exemplo de produto API pequeno em que clareza de contrato, scripts operacionais e prontidão para monetização importam mais que volume de features.
Repo público, renomeado de MailSieve-repositorio
O que inspecionar primeiro
Comece pela superfície do repositório: README, caminho de setup, CI, docs e os blocos de evidência que mostram que o sistema sobrevive fora do caminho feliz.
Abrir repositórioContexto
Eu queria um repositório que parecesse uma API produtizada e não um serviço interno. MailSieve classifica emails de signup contra domínios descartáveis e sinais leves de risco, com forte ênfase em clareza de contrato e verificação de deploy.
Problema
APIs pequenas normalmente falham no teste de portfólio porque parecem finas demais. Para valer a pena publicamente, esta precisava provar mais do que "responde JSON". Precisava de auth, rate limit, contrato OpenAPI, validação de ambiente, smoke tests e um caminho crível para publicação.
Restrições
- A API precisava rodar offline, sem forçar provedor externo.
- Ela precisava de opções simples de storage operacional para deploy inicial.
- A documentação pública precisava cobrir execução local e distribuição paga.
- O nome do repositório precisava de limpeza;
MailSieve-repositoriosoava inacabado.
Prova centralOpenAPI + auth + fluxo de verificação
Sinal do repositórioDocker Compose e smoke deploy
Preocupação operacionalRate limits e rotação de chaves
Arquitetura
client
-> API key auth
-> rate limiter
-> MailSieve service
-> listas de disposable e typo
-> provedor externo opcional
Rota de confiança da APIContrato primeiro, depois auth, classificação e verificação de deploy
01Receber um contrato estreito
A API parte de um schema OpenAPI claro para que request, auth e shape de resposta sejam legíveis antes mesmo da inspeção de código.
02Conter tráfego na borda
API keys e rate limiting entram antes da classificação profunda para segurar abuso antes da lógica principal.
03Classificar com sinais em camada
Domínios descartáveis, typos e lookups opcionais produzem uma resposta pequena, mas com cara de produto.
04Verificar a superfície de deploy
Docker Compose, healthchecks e smoke scripts fazem o repo parecer algo que outro engenheiro conseguiria publicar sem adivinhação.
Decisões e trade-offs
- Eu mantive os modos de persistência enxutos porque a meta era um produto inicial implantável, não uma plataforma completa.
- Eu adicionei Docker Compose e healthchecks porque confiança operacional importa até em API estreita.
- Eu documentei a publicação em RapidAPI porque prontidão para monetização faz parte da história do produto.
O que funcionou
- O contrato OpenAPI dá um ponto de entrada muito claro para o repo.
- Os scripts de chaves e de smoke deploy fazem o projeto parecer usável por outro engenheiro.
- A troca do nome para
MailSievecorrige um problema de branding que puxava o portfólio para baixo.
O que ainda está incompleto
- A API ganharia força com evidência melhor de performance sob volume.
- Ainda não existe endpoint público hospedado ligado ao repositório.
- A imagem social do repo ainda depende de configuração manual no GitHub.
Evidência
Checklist de publicação:
1. importar openapi.yaml
2. configurar auth x-api-key
3. publicar listing
4. rodar BASE_URL=<url> API_KEY=<key> npm run smoke:deploy