Подскажите, возможно ли такое архитектурное решение?

Почему просто не использовать список прокси?

Почему просто не использовать список прокси?

Хорошая идея, интересна финансовая сторона вопроса и на сколько реально найти прокси сервера, у которых большое количество белых IP, чтобы можно было делать ротацию?

Интересно, как такие задачи реализуют другие проекты.

Нужно смотреть как донор контента будет реагировать на большое количество запросов, возможно лимитов нет, возможно получится использовать ipv6 - прокси, тор или что-то в этом духе. Но как мне кажется, правильный путь договориться о доступе к апи и получать информацию открыто.

А данные точно нужны всегда актуальные или есть вариант обновлять базу по какому-нибудь интервалу?

Но как мне кажется, правильный путь договориться о доступе к апи и получать информацию открыто.

API есть и их можно использовать, но там есть ограничение на количество записей, который можно получить по одному запросу, оно маленькое, смысл теряется.

Нужно смотреть как донор контента будет реагировать на большое количество запросов, возможно лимитов нет,

Сайт крупного бизнеса, там 100% есть защита от повышенной нагрузки, вопрос только где лимит. Можно, конечно, попробовать в него упереться, но пока я ставлю паузы короткие в скрипте, чтобы не сработала защита.

По поводу тора здравая мысль и ipv6 прокси тоже. Спасибо.

А данные точно нужны всегда актуальные или есть вариант обновлять базу по какому-нибудь интервалу?

Нужны актуальные, т.е. свежие

написать js функцию на страничке, которая качнет нужное и зашлет на твой сервер. загрузка будет проходить через браузер и ip пользователя. минус - большее время переливания из пустого в порожнее.

Что мешает договориться с владельцами веб-сервера и получать от них нужные данные через API?

Что мешает договориться с владельцами веб-сервера и получать от них нужные данные через API?

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

API доступ предоставляется с существенными ограничениями на ?выгрузку данных, что делает невозможным работу проекта.

Получается вы даже тупо своровать не можете.

Была беда похожая с выгрузкой данных с стороннего сервиса, за пользование которым наша компания даже платила бобло. АПИ у них типа есть, но лишь для галочки, т.е. ничего с этого апи нормально не получить. А вот через браузер, после авторизации, в личном кабинете были и фильтры и таблички и экспорт в цсв. Так и пришлось писать грабилку с авторизацией, парсингом хтмл и прочей чепухой.

Чем я могу помочь? Только размышлениями.

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

А если там личной кабинки нет и апи нормальное, то пили так, чтобы сборщиков данных было много с разными айпи (любым из способов и их комбинаций: несколько айпи на сервак, прокси, отдельный шаред или впс). Где на каждый клиентский запрос к тебе запускается очередной твой сборщик (раунд робин или рандом).

Сделать приложение и отдать пользователю. Но вы же наверное хотите не задачу пользователя решать, а воздух продавать?

CORS

написать js функцию на страничке, которая качнет нужное и зашлет на твой сервер

Сам-то пробовал?

Как часто обновляется информация на внешнем сервисе? На сколько критично, если пользователь получит устаревшую информацию, например, на минуту?

ИМХО, я бы поднял службу, которая раз в n-минут/секунд обновляет данные с внешнего сервиса, производив необходимые манипуляции. Клиенту отдавал бы последние сохранённые данные. В итоге получаем: Фиксирование количество запросов к внешнему сервису; Масштабирование на любое количество собственных пользователей.

Остаётся вопрос критичности лага. Не думаю, что этот лаг в действительности имеет критичность, иначе с собственниками бизнеса уже были бы установлены соглашения.

Если не слишком тяжелая логика обработки и/или объем данных - обрабатывай на стороне клиента, прямо в браузере. Конечно если тебе не нужно на какую-то кофеварку 5-летней давности выводить. Сейчас браузеры достаточно хороши чтобы дробить цифры.

Да, говно-«бизнесмены» они такие.

Но вы же наверное хотите не задачу пользователя решать, а воздух продавать?

Мне кажется, что веб приложение удобнее поддерживать и разрабатывать, плюс клиентам будет удобнее пользоваться через браузер, нежели чем что-то устанавливать и морочиться потом с обновлениями.

можно как угодно сделать

Как часто обновляется информация на внешнем сервисе? На сколько критично, если пользователь получит устаревшую информацию, например, на минуту?

Минута - это не критично, а вот 3 часа уже не влияет на качество сервиса.

ИМХО, я бы поднял службу, которая раз в n-минут/секунд обновляет данные с внешнего сервиса, производив необходимые манипуляции. Клиенту отдавал бы последние сохранённые данные. В итоге получаем: Фиксирование количество запросов к внешнему сервису; Масштабирование на любое количество собственных пользователей.

Я думал об этом, с одной стороны мы сможем равномерно распределить запросы по времени, а с другой стороны нам придется делать их излишне часто, т.к. мы не знаем когда пользователь захочет их посмотреть.

Если предположить, что средний пользователь будет обращаться к системе раз в день, то сделав загрузку данных по его обращению, мы запросим данные тоже один раз в день. В тоже время, если загружать данные регулярно, чтобы держать их актуальными, мне придется делать запрос раз в 3 часа, что повысит, а не снизит нагрузку на донора.

PS Вообще спасибо за советы, действительно очень много толковых и дельных советов. Есть что попробовать.

можно ли как-то архитектурно сделать так, чтобы выгрузка данных происходила не напрямую с веб сервера на мой сервер, а через комп пользователя

Нельзя.

написать js функцию на страничке, которая качнет нужное и зашлет на твой сервер. загрузка будет проходить через браузер и ip пользователя.

Местные трехзвездочные аналитики про cors не слышали? Жесть.

Тогда уж сразу на фронте и обработать, нафиг сырые данные туда-сюда гонять.

Так там нечего обрабатывать будет, запрос не пройдёт.

как такие задачи реализуют другие проекты

Договариваются с владельцем.

интересна финансовая сторона вопроса

Вангую, что договориться будет дешевле, чем покупать 100500 ip на проксе.

Я думал об этом, с одной стороны мы сможем равномерно распределить запросы по времени, а с другой стороны нам придется делать их излишне часто, т.к. мы не знаем когда пользователь захочет их посмотреть.

Записывай время последнего обновления базы на своём сервере, и когда пользователь делает запрос — сравнивай с текущим. Если разница больше желаемой — обновляй, если нет, выдавай какие есть.