MisterN, прошу прощения, с wget плотно не работал, не знал у него есть опция для забора всех зависимостей. Тогда, конечно, необходимости в стороннем софте нет.
Чтобы все работало локально, нужно качать не только HTML но и другой контент (js, css, изображения). Используйте специализированные программы, типа teleport pro.
forklive, если в JSON приезжает не все что нужно, то забираем HTML один раз, затем забираем только JSON через определенные промежутки времени. Я так понимаю, события не меняются на самой странице? А если меняются значит либо они как то еще приезжают на страницу, либо сама страница рефрешится. В зависимости от того как работает конкретный сайт, вы пишете логику парсера.
Насчет другой страницы с другими коэффициентами. Если страница на том же сайте, то логика у вас будет такой же, только другая точка входа (по сути парсер будет такой же как для первой страницы, без лишнего кодинга). Если на разных, то тут в любом случае описывать логику, поскольку разметка наверняка будет разной.
Хедлесс браузер много прожорливей решения написанного с использованием инструментов без запуска JS. Вы не хотите разбираться с JSON и работой каждого сайта, но вам все равно придется разбираться с версткой каждого сайта и под каждый писать отдельную логику. Поэтому технически тут нет разницы, с моей точки зрения, в сложности что парсить json или html. Я бы не использовал headless browser :) но это мое личное мнение.
А коллега мой парсил на Go, без headless :)
Danil Sapegin, Дело даже не в скорости, а скорее в этичности. 1 или 2 запроса на ресурс, чтобы забрать данные со страницы стандартным HTTP запросом, даже в случае когда сайт работает полностью на JS, лучше чем несколько десятков, сделанных хедлесс браузером. Дополнительным плюсом является то, что бот в этом случае не виден для аналитики и метрики и поэтому не портит статистику.
Я предпочитаю потерять вначале единицы или десятки минут на разбор работы сайта, зато в долгосрочной перспективе сэкономить на машино-времени. Но это в общем то просто мое мнение :)
Зато нагрузка на сайты доноры тоже возрастает в разы :) да и на сервер на котором запускается решение основанное на хедлесс браузере + скорость работы очень низкая. Писать парсеры конечно же будет проще для сайтов, которые работают на JS, однако все будет весьма малоэффективно.
Далее - токен. Если он меняется, можно его забрать на странице https://www.kinopoisk.ru/premiere/ru/2018/month/4/
Он находится в ноде script: var xsrftoken = 'CSeIvLiyQOaq4XjQIN-fr63hYek_Fop5xWtV0vnDZRs';
Если не меняется, можно захардкодить (но это в принципе неправильно :))
Ilya Vegner, на самом деле все просто, открываете страницу в любом современном браузере, затем открываете инструменты разработчика (встроены в любой современный браузер). Так как мы ожидаем что данные приезжают отдельно через XHR запрос, идем во вкладку Network/Сеть и смотрим, что приезжает в этих запросах, находим нужный (с данными статистики) и смотрим как он делается (GET/POST) и какие параметры передаются, в данном случае это GET запрос, поэтому можно просто скопировать URL запроса и попробовать открыть его в отдельной вкладке браузера. Если открывается, все хорошо. Если нет, то надо изучать то, что передается в заголовках и стремиться максимально копировать запрос в парсере.
val_vp, не за что :) я всегда стараюсь использовать селениум как крайнюю меру, предпочитаю разобраться в механике сайта. Селениум своего рода abuse для сайта, во первых количество запросов сильно увеличивается для забора одной страницы, во вторых забор страницы селениумом учитывается в аналитике и метрике и в большинстве случаев как отказы.
уменьшение количества регекспов улучшают читабельность кода, облегчают майнтенанс. Если идет работа с сотнями парсеров, это достаточно критичный момент.
Bjornie, tor будет весьма медленно, купите себе нормальные прокси, они стоят от доллара за штуку в месяц. Парсить под аккаунтом я бы не стал, всегда лучше делать анонимно.