Pipelines de dados · Mobile com suporte offline
Observador de Concursos
Uma plataforma de inteligência para concursos públicos que conecta monitoramento de fontes, acompanhamento de mudanças em documentos e um aplicativo que funciona offline.
- Atuação
- Backend, pipelines de dados e sincronização mobile
- Tecnologias
- FastAPI, PostgreSQL, Celery, React Native
O problema
Os editais de concursos estão espalhados por portais institucionais. Datas mudam, documentos são atualizados e os candidatos precisam acompanhar tudo, mesmo com uma conexão instável.
Reunir coleta, versionamento e acesso do candidato em um único sistema. Um catálogo com 99 definições de fontes alimenta os coletores em segundo plano; o aplicativo mantém uma cópia local e reconcilia as mudanças quando volta a se conectar.
Decisões de engenharia
Registrar as mudanças de forma explícita
Hashes SHA-256 e registros de versão distinguem um edital alterado de outro já processado. O histórico de execuções ajuda a diferenciar um resultado vazio de uma falha no portal.
Separar as tarefas demoradas
Celery e Redis cuidam da coleta agendada, da extração e das novas tentativas. O FastAPI disponibiliza registros estruturados e pontos de controle para sincronização.
Continuar após perder a conexão
O cliente em React Native e Expo armazena os dados em SQLite. Favoritos e alertas entram em uma fila local de saída e são reconciliados com o backend após a reconexão.
Um fio que você pode
seguir até o fim.
Workers agendados coletam editais públicos por HTTP, automação de navegador e extração de PDFs. O Redis organiza a fila e as novas tentativas. O registro da execução distingue um portal indisponível de outro sem novos editais.
O que foi desenvolvido
API, worker, agendador, PostgreSQL e Redis em contêineres, além de um cliente mobile com suporte offline. O repositório inclui dados de teste dos conectores, verificações de idempotência e sincronização e documentação operacional. As 99 fontes compõem o catálogo configurado; isso não significa que todos os portais estejam ativos.
Ver código-fonteEvidências de um piloto
Um sistema que dá para conferir.
O piloto documentado acompanhou registros reais da API até o cliente web. Busca, filtros, detalhes e histórico de revisões foram inspecionados, com os limites registrados junto dos resultados.
- seleções sincronizadas no cliente
- 32
- fontes representadas no piloto
- 31
- versões armazenadas
- 48
Os dados chegaram à interface
Login, renovação de sessão, checkpoints, 32 detalhes e revisões passaram pelo proxy web. O navegador exibiu as 32 seleções; o filtro de inscrições abertas reduziu aquele resultado a oito.
O mesmo edital não pode se multiplicar
O repositório inclui um teste controlado de idempotência: a primeira coleta cria um registro e uma versão; repetir a coleta com os mesmos dados não cria nenhum dos dois. É um teste com dados controlados, separado do piloto real.
A reconciliação offline tem uma verificação própria
Scripts específicos cobrem favoritos, alertas e reabertura do app. Eles permitem inspecionar o fluxo de ida e volta esperado, mas o piloto de setembro não testou rede desconectada, aparelhos nativos nem novas ações offline.
São resultados de um piloto datado, não um painel de disponibilidade ao vivo. Eles não certificam as 99 fontes configuradas. O relatório também registra localizações ausentes, publicações estruturadas vazias e rótulos de datas e mudanças pouco claros.