Pitch: O mercado paralelo de vagas dev que roda há anos no GitHub
Existem milhares de vagas dev sendo postadas todos os dias num lugar que quase ninguém abre
Tem um mercado de vagas paralelo rodando há anos no GitHub, e a maioria dos devs nunca abriu.
Não é exagero. É infraestrutura.
Empresas como Strider e Coodesh divulgam vagas com frequência em repositórios como o backend-br e o frontend-br. Quem acompanha essas issues vê oportunidade chegando antes de virar post no LinkedIn. Quem não acompanha, perde.
E isso é só a ponta brasileira.
Existem milhares de repositórios parecidos espalhados pelo mundo. Comunidades em inglês, espanhol, alemão, japonês, com o mesmo padrão: vaga vira issue, issue vira mercado, mercado vira oportunidade pra quem chegar primeiro. O problema é óbvio. Ninguém abre 50 abas pra acompanhar isso na mão.
A solução que eu queria que existisse
Construí o openings.dev.
É um agregador que junta vagas de comunidades do GitHub do mundo inteiro em um só lugar. Filtra por tecnologia, país, comunidade e empresa. Página de detalhe pra cada vaga. Diretório de comunidades, diretório de autores, listagem por repositório.
Tudo estático. Tudo open source. Zero servidor.
Por que estático faz sentido aqui
A maioria dos agregadores de vaga roda backend, banco, fila de scraping, painel admin. Caro de manter, fácil de quebrar.
Eu fui pelo caminho oposto:
- Dois repositórios separados. Um cuida dos dados, outro cuida da interface.
- openings-dev/data faz o scraping, normaliza e publica snapshots em JSON direto no Git.
- openings-dev/openings é um Next.js exportado como site estático que consome esses JSONs via raw.githubusercontent.
O front lê os arquivos no momento do build. Gera todas as páginas estáticas. Sobe pra um host de página estática qualquer. Custo de runtime: zero.
Atualização dos dados é só um novo commit no repositório de dados, novo build do front, deploy.
Decisões que tomei pelo caminho
Algumas das escolhas que valeram a pena:
- Snapshots segmentados por país. Em vez de um JSON gigante, dividi em shards. Isso permite gerar páginas estáticas por comunidade e por usuário sem estourar memória no build.
- Manifest central. Um único
manifest.jsonaponta pra todos os outros arquivos. Mudou a estrutura dos dados, é um arquivo só pra atualizar. - Page lookup precomputado. Paginação resolvida em build time. O front só lê o JSON da página que precisa.
- Sem mock, sem fixture, sem fallback local. Se o dado não tá no repositório de dados, ele não existe pro front.
O que ainda quero resolver
- Parser melhor. Issue de vaga não tem padrão. Extrair stack, senioridade, modelo de contratação e remuneração direto do texto cru ainda é o ponto fraco.
O convite
Se você acompanha alguma comunidade do tipo que ainda não tá listada, abre uma issue no repositório de dados. Se quiser usar, o site tá no ar: