Alex Solomaha

https://core.telegram.org/bots/api#leavechat же

uplabs.com

Получаете post данные, декодируете их в массив, траверсите массив и грузите данные в модели и сохраняете их. Допустим вы передаете данные в post параметре arr а модель у вас называется Model

$data = json_decode(\Yii::$app->request->post('arr'), true);
foreach ($data as $chunk) {
    $model = new Model();
    $model->attributes = $chunk;
    $model->save();
}

Чтобы модель корректно сохранилась в бд нужно чтобы ее свойства удовлетворяли ее правилам валидации (см. метод rules в классе модели). Если не сохраняется в бд, можно проверять на ошибки, например вместо обычного сохранения прописывать

if (!$model->save()) {
    var_dump(['erorrs' => $model->errors]);
}

Ошибки выводятся в STDOUT просто для наглядности примера, вообще конечно их лучше не выводить сразу а логировать куда-то или оформлять в нормальный api ответ запрашивающему.

Ну если человек сидит с одного IP и его не банят, значит надо сделать так, как будто по сайту ходит "человек".

Для этого предлагаю вспомнить общеизвестную задачу "банерокрутилку". Имеется N банеров. Их надо прокрутить каждый по 1 разу и за K секунд.

В вашем случае в качестве банеров выступают URL-ы. K секунд делим на Т url-ов и получаем время на каждую ссылку. Но. Чтобы внести не детерменированность, то делаем это с разными промежутками времени перед между очередной итерацией парсинга.

Посмотрите внимательно на вывод:

site.ru/?page1
site.ru/?page2
...
site.ru/?pageN .

Видите?

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

Как правило люди пишут "влоб" потому что головою думать не хотят!

Надо сделать "прогулку" по сайту так: site.ru/?page15, site.ru/?page179, site.ru/?page1, ... Одну страничку за 5 сек посмотрели, а другую 1минуту и т.д. Понаблюдайте за собою, как вы ходите по сайтам? Вы разве за 1-2 сек успеваете прочесть статью? Уверяю вас вы хаотично бродите по сайту. То в личные сообщения, то в избранные, то в поиск заглянете, то из выдачи поиска по какой-то статье. Вот и в парсинг вносите хаотичность

Конечный вывод в том, что вам нужно выбирать между:

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

Либо нарисовать, либо использовать Font Awesome, Free Icon Pack, Fontelico

короткая ссылка - это id в базе сервиса. его невозможно "рассшифровать" без посещения сервиса.

Прикинуться браузером и попробовать разжать страницу

stackoverflow.com/questions/26497556/php-curl-emul...

curl --compressed msk.gorko.ru

1) Нет. Обычный сайт - это одно короткое соединение на один запрос к серверу. Время жизни соединения ограничено одним request (пришёл запрос - соединение создалось, отдали ответ - оно умерло). Выигрыша по сравнению с обычными синхронными фреймворками нет. А так как нода - однопоточная, то может случиться так, что соединение, в котором выскочила ошибка убьёт всё приложение.
2) Нет. Бери любой развитый MVC-фреймворк на любом языке, так легче.
3) Для тех, где нужна асинхронность: прикрутить вебсокет-чат для готового сайта, работа с очередями сообщений (чтобы принимать их в неблокирующем режиме), рассылка уведомлений, запись в БД без блокировок, и т.д. Т.е. обычно его используют там, где надо держать много одновременно открытых соединений, каждое из которых не требует много процессорного времени, но может тормозить из-за IO.

Судя по всему так же как и в 1,1.

'/products/<path:.+>' => 'category/view'

function actionView($path) {
    // это пример. Все зависит от архитектуры
    $category = Category::findByPath($path);
}

Так же если хотите что бы все было более грамотно - реализуйте правило в виде инстанса класса UrlRule.