Отношение к веб-скрейперам как... Заметка
DZone.com Feed на русском

Отношение к веб-скрейперам как к производственным услугам

Большинство команд воспринимают поломку веб-скрапера как рутину. Кто-то замечает некорректные данные, открывает страницу в браузере, исправляет селектор и перезапускает. Это работает, когда у вас один скрапер и кто-то ежедневно просматривает его вывод. Это перестает работать, когда у вас их дюжина, и поломка проявляется через неделю в виде странной цифры в отчете ниже по цепочке. В этой статье я расскажу, как я построил скраперы, которые каталогизируются, проверяются на работоспособность, отслеживаются и ремонтируются, как и любая другая продакшн-служба, при этом LLM предлагает исправления, а обычный Python решает, будут ли эти исправления внедрены.Проект возник на хакатоне WeMakeDevs, где он занял первое место. Сам продукт невелик: он извлекает данные телегида за примерно двенадцать дней от трех стриминговых провайдеров, ранжирует десять лучших предстоящих фильмов и десять лучших предстоящих шоу и позволяет записать любое из них на Philo одним кликом. Я опущу описание продукта и сосредоточусь на технической части: правилах отклонения, модели состояния, верификаторе и коде, стоящем за каждым из них. Эти компоненты применимы к любой команде, которая использует скраперы, или к любой команде, которая позволяет LLM изменять рабочую систему.