Илья Чубаров, откуда такие ограничения? я честно говоря не прочитал сего в вопросе автора. Ну да ладно - у нас есть Chain Jobs в которые мы можем запихать любую последовательность и прописать что будет происходить при падении какой то задачи из списка. И обрабатывать эти цепочки в один поток.
Илья Чубаров, я задачу понял несколько иначе. есть джобы которые обращаются к какому то сервису и могут его задолбать и начать получать какой нибудь 429.
Ну первое банальное решение класть задачи от этого конкретного сервиса в конкретную очередь. И разбирать это одним воркером. И мы никогда не получим что у нас несколько воркеров полезут в один сервис и его задолбает. Оно будет их разбирать последовательно.
Второе решение, мы хотим зачем то запускать несколько воркеров на такие сервисы. Хотя вообщем то это не надо. Ну ок пишем свой миддлеваре - и свой rate limit который будет основаться скажем на основе количества обращений к сервису, ну который придется где вести - редис, мемкеш, база, файл. И откладывать его согласно каким то правилам.
Третье. Зачем нам fail table. мы можем отлавливать конкретную ситуацию когда мы ловим 429 - и шарашить delay().
У вас то какие проблемы были?
З.Ы. Если вы не нажимаете кнопку ответить - мне уведомление не сваливается.
Простите а зачем такие сложности? Выполнять определенный тип задач в один поток можно - просто отдав под это одну очередь и разбирать ее в один поток. Если нужно что то более сложное - то job middleware
не совсем понятно. что мешает вам создать 1 очередь где будут задачи с обращениями к сервисам с лимитами и разбирать ее одним воркером? или где то хранить количество обращений и откладывать задачи если лимит превышен?
Эмиль 🔥, ну не удачно вы набросали. Ни хрена не понятно что вы хотите выбрать. Выбрать все страны и если есть приджойнить к ним какого то пользователя из этой страны?
verygoodboy, try catch должен быть в сервисах - что бы вы могли выбросить дальше не просто RequestException а свой подтип эксепшна который будет указывать на то какой именно сервис отвалился или чего еще случилось. Дальше в зависимости от того что мы хотим, если мы хотим тупо вьюху вывести - можете у этого эксепшн захреначить метод render
verygoodboy, а почему не может быть какого нибудь сервиса который на вход получит пользователя и будет дальше работать с сервисами? а контролер только его вызовет?
verygoodboy, но
ну первая часть да, а про контроллер я ничего не говорил. а зачем что бы контроллер занимался передачей данных из одного сервиса в другой? почему сервис с логикой сам не может это сделать?
verygoodboy, Ну сильное подозрение что вам скажут что ваш сервис который отвечает за работу с каким апи определенно должен отлавливать экспешн от коннекта и выбрасывать свой эксепшн - что бы работать уже с SiteApiRequestException - а не просто с RequestException которая не пойми с какого сервиса прилетело. И это вам скажут не только ларавельщики.
