Добрый день, коллеги!

Давно не писала, но за это время накопилось много интересного — и про разработку, и около неё. Держитесь)

Недавно завершила проект по автоматическому сбору данных для заказчика (подробности идеи, увы, под NDA). Но есть общие технические моменты, которые касаются целого класса подобных задач, — ими и хочу поделиться.

Кратко зафиксирую самые яркие грабли, на которые наступила.

О чем речь Роботы-«пауки» открывают браузер, ходят по страницам и собирают данные в структурированном виде. Звучит просто. А вот с чем я столкнулась на практике.

1. При создании объекта Страницы (Page в библиотеке puppeteer) выделяется дополнительная память для сессии браузера. Из-за этого нужно выделять пул таких объектов и переиспользовать их, при этом количество таких объектов зависит от компьютера. Логично? Да. Но если потребуется оптимизировать подобную программу по памяти, обратишь внимание на циклы, на явно используемые конструкции, но не на внутрянку конструктора библиотечного объекта. Это неочевидно

2. Капчи - это бесконечные "проверки на человека", от которых реально трудно избавиться. Оказывается, сайты ведут внутренний счётчик подозрительности. Если его значение переваливает за порог — начинаются проверки.

Их "коварство" для разработчика в том, что приходится симулировать поведение реального пользователя: - Скроллить страницу, делать задержки, имитировать плавные движения мыши - Делать таймауты между переходами - Выдерживать паузу перед повторными визитами, чтобы не получить Too Many Requests и блокировку по IP - Обнаруживать появление капчи (а её вёрстка бывает совершенно разной) - Использовать прокси и менять их хотя бы раз в месяц - Сохранять куки, историю, локальное хранилище — всё, что характеризует "живой" браузер

Появление капчи сильно усложняет отладку основных фич и существенно увеличивает время разработки.

Если вы тоже пишете парсеры — дайте знать в комментариях, как боретесь с капчами. Обменяемся опытом