Как стать автором
Обновить

Комментарии 23

НЛО прилетело и опубликовало эту надпись здесь
Т.к. уже работал с этим сайтом и платформой Shopify
все зависит от зарплаты :D
НЛО прилетело и опубликовало эту надпись здесь

Как поживает скрейпинг фротенда при вашем подходе, когда всё содержимое страницы загружается AJAX скриптами? Нам приходится целым браузером ходить по страницам

Возможно вы не до конца поняли, что я хотел донести в этой статье. Что вам не нравится и какие есть предложения?

Я то понял. Просто вы описываете простой случай, когда вам сервер отдаёт страницу с данными. А у нас чаще встречаются ситуации, когда сервер отдаёт практически пустой Html с пачкой JS скриптов, которые асинхронно начинают подтягивать данные на страницу и отдельная проблема даже понять, когда эта страница "полностью прогрузилась и готова к использованию". Имитировать логику всех этих JS вручную ооочень трудозатратно.

В этом случае мы смотрим какие точки backend api тоскают данные js файлы и собираем воедино картину. Зачастую именно грамотный поиск эндпоинтов освобождает от использование хэдлес браузеров. Да и статья расчитана исключительно как вводная.
А вот это интересно. Буду признателен, если расскажете поподробнее. Спасибо
Это все хорошо до тех пор, пока не сталкиваешься:
1. С хорошей, нестандартной captcha
1. С защитой от ботов с помощью сервисов типа perimeterX, Netacea, dataDome и прочих.
3. С защитами на основе user fingerprinting.
И тогда порой уже без полноценного браузера на базе chrome не обойтись. Даже headless режим детектируется при известной сноровке (отрисовка определенных картинок с помощью движка, триггер по использованию мышки, подключенные плагины, быстро закрытая вкладка и прочие варианты).
Как итог, приходишь к созданию эдакого фреймворка типа scrapy, который бы позволял работать с удаленными сайтами с помощью различных вариантов подключения: requests, selenium, headless, chrome.
А уж что говорить когда необходимо обеспечивать поиск по данным в реальном времени, тут и каждая секунда дорога, и проблем бывает выше крыши.
За ссылочку спасибо не знал про такие отпечатки. Но так вы правы любой более менее большой скрапер это 98% requests и 2% (selenium или браузер + те или иные способы обхода/решения капчи и периметра) правда распределение полезной информации на эти подходы увы скорее диаметрально противопложное. Кейсов в реальном времени увы(или к счастью) пока не встречал в практике.
Имею огромный опыт в парсинге. Пару раз встречал капчу, и то, по жадности. +100500 защит используют наверное экзотические малоизвестные сайты. Какой смысл навешать много защит от парсинга, если их все равно обойдут. К тому же, если навешать на сайт много защит, они со 100% вероятностью будут ложно срабатывать. А это раздражает обычных пользователей. Пользователи просто уйдут из сайта. Это как я яндексом. Есть у них сервис, в котором можно посмотреть сколько запросов в месяц по ключевым словам. На каждый запрос, нужно ввести капчю, которая 1 из десяти понятна. Теперь я не пользуюсь яндексом, пусть сами вводят свою капчю.
image

Попробуйте вашим способом получить список документов вот с этой, например, страницы:
https://www.mos.ru/authority/documents/

Дёргаем www.mos.ru/api/documents/v1/json/list.php?filter=%7B%7D&page=1
В ответе видим красивый json, а листаем страницы меняя значение page=

Получение документа по id — www.mos.ru/api/documents/v1/json/detail.php?id=43437220

Работать с подобными сайтами даже проще и приятнее. Не нужно возиться с парсингом html, потому что как правило там json в ответе.
А enpoint'ы находятся через DevTools максимум за минуту.
Бывают случаи когда и целым браузером приходится ходить, но это редкость, обычно просто запросов достаточно. Ходячий браузер с сервером тоже просто запросами общается, но иногда повтор логики javascript банально не соотносится с объёмом и частотой добываемых данных, и проще использовать браузер. Вопрос больше в плоскости необходимых усилий.
В своих задачах я не испльзую браузер для скрапинга, т.к. это замедляет выполнение задач для нашей мониторинговой системы, в которой важна каждая секунда, чтобы быть быстрее конкурентов. Поэтому я отдельное внимание уделяю поиску необходимых эндпоинтов.
Ну у вас есть смысл и в js'e и в куках переменные нужные искать и регулярки использовать вместо html парсера. А так есть целый пул кейсов, где данные нужно обновить только раз в день, или js уж больно замудрённый и проще в лямде селениум развернуть, или фантом там.
Если ценность в скорости и экономии ресурсов конечно разберёшь весь фронт по полочкам и ещё и старые едпоинты найдёшь. =)

P.S.
Учитывая что вас спрашивают выше, то совет, по подробнее остановится на хром инструментарии видимо использование вызывает у людей сложности. )
Спасибо

Хотелось бы узнать причину отклонения комментария.
В последнем абзаце автор предлагает написать в комментах сайт для примера — я предлагаю reformagkh.ru.

Проанализировав ваш профиль я пришёл к выводу, что возможно вы являетесь фэйком. А ваше предложение основано на личных интересах для дальнейше монитизации, не более. Если я не прав, то прошу прощения. Но это моё мнение
Если необходимо предлагать только то, что не «основано на личных интересах» — стоит писать об этом прямо. Потому что из контекста это не следует.
«Дальнейшая монетизация» это зло?
Мой проект скрапинга бесплатен. И он на js. Велкам.
Такой парсер пишется за 3 часа. Какая «монитизация»?
Любая работа стоит денег так что не надо перегибать. То что в данном случае сайт максимально просто отдаёт все данные не значит что это всегда так работает. А монетизация зависит от фантазии и лени людей в поиске данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории