Ainda estou aprendendo n8n e tenho um pequeno projeto.
Quero monitorar uma página de agendamento governamental (similar a uma página de agendamento de NBI) e receber notificações apenas quando algo importante muda, como novos horários disponíveis ou uma atualização de status.
Não quero fazer scraping agressivo ou quebrar nenhuma regra do site. Só preciso verificar a cada alguns minutos e enviar uma notificação por Telegram ou email se houver uma mudança real.
Qual é a melhor abordagem em n8n para isso? HTTP Request + HTML Extract + comparar com resultado anterior? Ou existe um workflow melhor?
Gostaria de ouvir como outros fazem esse tipo de monitoramento sem ser rate-limited.
Oi @jozerizzel Bem-vindo!
Aponte a Solicitação HTTP para o endpoint JSON que o próprio calendário de reservas chama, em vez do HTML renderizado. Depois armazene a resposta ETag nos dados estáticos do workflow e devolva-a como If-None-Match na próxima consulta. As consultas inalteradas retornam 304 sem corpo, então ative Incluir Cabeçalhos de Resposta e Status para ler a ETag, e Nunca Errar para que um 304 não falhe a execução.
Os dados estáticos só são salvos em uma execução de workflow publicado acionada por seu gatilho, então cada execução de teste manual parecerá como a primeira consulta.
Obrigado pela explicação detalhada, realmente aprecio.
Não tinha pensado em usar o endpoint JSON com ETag e If-None-Match. Isso soa muito melhor do que comparar todo o HTML a cada vez.
Também obrigado por explicar o comportamento dos dados estáticos. Eu estava confundido porque todo teste manual parecia uma primeira execução, agora sei o porquê.
Vou atualizar meu workflow e testá-lo em um trigger publicado. Espero que isso reduza solicitações desnecessárias e evite ser bloqueado.
Obrigado, esse fluxo de trabalho parece muito mais fácil de entender.
Acho que vou testar isso primeiro antes de torná-lo mais avançado com ETags. Meu objetivo principal é apenas ser notificado se algo mudar na página de agendamento do NBI online, então não preciso ficar verificando manualmente o dia todo.
Vou construir esse fluxo e ver como funciona. Se o site ficar muito pesado para fazer polling, então vou investigar a abordagem JSON/ETag que foi mencionada antes.
Oi @jozerizzel, você teve a chance de testar este fluxo de trabalho? Ele notificou você sobre as mudanças de agendamento que você precisava, ou você enfrentou alguma dificuldade?
Estou construindo um iniciador pequeno de mudanças de site n8n e gostaria de entender onde as abordagens existentes ainda ficam aquém. Obrigado!
Estou fazendo algo parecido (monitorar páginas de listas em várias plataformas), e alguns pontos fazem a maior diferença:
1. Frequência é a variável principal, não a técnica. A maioria dos bloqueios que vi vinha de „consultar com muita frequência", não de um problema com a requisição em si. Se os dados subjacentes mudam apenas algumas vezes por dia, consultar a cada 5 minutos não vai trazer mais nada, só vai desperdiçar a conexão. Depois que mudei para um agendamento fixo, deixei de ser bloqueado.
2. Compare campos, não a página inteira. Comparar todo o HTML da página significa que toda vez que o site muda o layout você recebe um alerta falso. Extraia apenas os campos que você realmente se importa, faça um hash deles, e compare com a última vez. Menos alertas, e cada um é real.
3. Mantenha um registro de „o que você viu". Armazene um ID para cada item, e antes de completar uma nova rodada, compare. Esta etapa é a chave para transformar „tudo nesta página
Algumas coisas que fizeram a diferença para mim, executando um monitor similar em
vários sites de listagens:
Frequência é a variável principal, não a técnica.
A maioria dos bloqueios que vi vieram de polling muito frequente, não da
requisição em si. Se os dados subjacentes mudam apenas algumas vezes por dia,
verificar a cada 5 minutos não traz nada e custa a conexão. Passei de polling
frequente para um cronograma fixo e os bloqueios pararam.
Diff em campos, não na página.
Comparar HTML da página inteira te dá falsos positivos toda vez que fazem uma
mudança de layout. Extraia o punhado de campos que você realmente se importa,
faça hash deles e compare contra a execução anterior. Menos alertas, e os que
você recebe são reais.
Mantenha um registro do que você já viu.
Armazene um ID por item e verifique novas execuções contra ele. Isso é o que
transforma “aqui está tudo na página” em “aqui estão os três que são novos
desde a última vez” — que geralmente é o que a pessoa lendo a saída realmente
quer.
Alerte também sobre o silêncio.
Se o monitor retorna zero mudanças por várias execuções seguidas, isso pode
estar correto, ou o seletor pode ter quebrado. Vale a pena uma notificação
de qualquer forma.
Se o site tem uma API oficial ou feed, quase sempre vale a pena a configuração
extra mesmo quando scraping parece mais rápido no primeiro dia.
