но другого применения пока не вижу

но другого применения пока не вижу

Вот пример: Отправляем запрос в банк на привязку карты, через batch цикличное задание на проверку статуса, в then меняем у пользователя флаг о том что привязка в процессе, в finally отправляем запрос в банк на получение данных карт, и дергаем флаг на то что карта была успешно привязана, в catch дергаем флаг об ошибке привязки

Элементарно же вроде

catch - задание было не успешно например выпал эксепшен или количество попыток закончилось

then - задачи отправились в очередь но еще не выполнены

Окей, задачи ж сами по себе могут быть с несколькими попытками

finally - все задачи выполнены, прям все

Окей, задачи ж сами по себе могут быть с несколькими попытками

так я и говорю про цикличный джоб, сам джоб один

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

finally выпадет только тогда, когда оба джоба закончили работу

вы помеделнее, я фотографирую

ну так джоба сама может фейлиться, если привязки нет, следовательно она рестартанет через N минут. а если проверка прошла, успешно завершится и сменит статус юзера

Иначе нам например в том же двх нужно удалить данные если статус привязки мы так и не получили

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

ну так джоба сама может фейлиться, если привязки нет, следовательно она рестартанет через N минут. а если проверка прошла, успешно завершится и сменит статус юзера

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

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

Раньше обработка кэтчей делалась в самом джобе

технически это не костыль

Но это не очень удобно

Как и обработка собственно количества повторений

согласен, сейчас код самой джобы можно сильно сократить

согласен, сейчас код самой джобы можно сильно сократить

Что плюс, если мы используем например очереди БД

Потому что код джоба хранится в БД

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

там разве сам код хранится?

там разве сам код хранится?

да

Посмотри в табличку))

хуйня так-то 🙂

хотя я понимаю, зачем это сделано

у нас в проекте мы храним ссылку (класс) и входные параметры, а воркер код подымает из файлов

хуйня так-то 🙂

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

А так у них зафиксирован код, в момент добавления в очередь

хотя нет, теперь не понимаю. потому что это не решает никакой проблемы

воркер все так нужно ребутать после деплоя

Это наоборот, очень правильный полход, с редисом например также, но там не так критичен объем данных по этому на объем кода в джобе можно забить

воркер все так нужно ребутать после деплоя

Зачем?

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

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

зафейлятся скорее всего - да, но могут и данные поломать

API проекта - это всмысле интерфейсы в самом проекте, не какое-то стороннее апи.

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

Да, если джоб ссылается на бизнес логику в сервисе например, это тоже надо учитывать, при разработке, ща у меня чет мозги подзависли, если в пять минут отвиснут я тебе кину пример как делать безопасные джобы с учетом их "Кэширования"

Чет не могу вытащить из головы пример) Короче так надо и это очень бест практика, но бест практика из разряда когда ты делаешь какую то пиздецовую ошибку и думаешь "Так вот почему это тут сделано так, а не иначе" )))

Ну спорно про так надо. Так надо в ларавел, потому что Тейлор так сказал 🙂

Я говорю, что у нас своя реализация и у нас надо по другому, потому что наступали на грабли

Ну спорно про так надо. Так надо в ларавел, потому что Тейлор так сказал 🙂

Просто еще не сталкивался с проблемами которые решает данный подход, и так не тейлор сказал, это общепинятая практика, например bash скрипты кэшируются на момент выполнения, и даже если ты обновишь файлы - пока из задач они не уйдут - они не обновятся, и это не единственный пример

так тут получается двойная работа

воркер на момент запуска ведь тоже кеширует весь код

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

воркер на момент запуска ведь тоже кеширует весь код

Воркер может упасть, а джобы должны выполнится именно такими какими они были в момент добавления

Во, вспомнил пример из жизни, сейчас напишу

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

Вот для таких ситуаций и нужно кэширование кода джобов

По этому например версия документов у нас передается прямо в джоб, а все что приходит в джоб пропсами - кэшируется вместе с кодом

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

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

Вообще в ларавел очень мало делается вещей "Просто потому что Тейлор так хочет", ты меньше чатики Российские читай где каждый второй - бог программирования и вот он бы, вот он бы точно написал бы идеальный фреймворк

У нас типа кстати недавно уволили который когда пришел на собеседовании говорил что он пишет свой фреймворк потому что все текущие какой то говно, и он точно знает какой фреймворк людям нужен, ну и первый месяц всем на уши приседал своими "гениальными" идеями, только вот незадача, он оказался настолько слаб в работе что даже не справлялся с рутинными задачами, а что то более сложное ему за 4 месяца никто так дать и не доверил

Очень показательно для ру - комьюнити

У нас типа кстати недавно уволили который когда пришел на собеседовании говорил что он пишет свой фреймворк потому что все текущие какой то говно, и он точно знает какой фреймворк людям нужен, ну и первый месяц всем на уши приседал своими "гениальными" идеями, только вот незадача, он оказался настолько слаб в работе что даже не справлялся с рутинными задачами, а что то более сложное ему за 4 месяца никто так дать и не доверил

Желание написать свой фреймворк вполне нормальное Начинаешь понимать как это в принципе работает, если копаешься даже в тех самых симфони компонентах

С другой стороны когда чел банально за mvc на шарит изначально, а уже что-то пилит

это конечно да

Желание написать свой фреймворк вполне нормальное Начинаешь понимать как это в принципе работает, если копаешься даже в тех самых симфони компонентах

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

Желание написать свой фреймворк вполне нормальное Начинаешь понимать как это в принципе работает, если копаешься даже в тех самых симфони компонентах

В ру комьюнити Лары тоже принято обсирать решения Тейлора, откуда видимо и понес свое мнение оратор выше, он считает что достаточно квалифицирован чтобы судить решения других хотя до конца даже не понимает в чем преимущества колбэков при вызове джобов

За то ебучую Yii2 боготворят за совершенно отбитые решения которые при масштабировании несут тысячи проблем

юии любят за скорость из коробки и просту всяких крудов

за что любить его больше - я не знаю

юии любят за скорость из коробки и просту всяких крудов

Именно так, но почему то эти люди не задумываются почему в ларе такую простоту не делают, а наоборот все больше выпиливают

Именно так, но почему то эти люди не задумываются почему в ларе такую простоту не делают, а наоборот все больше выпиливают

ну "тейлор так решил" тоже имеет место быть например абсолютно непонятное решение навязывать мне свой jetstream

и если я хочу использовать laravel ui он мне говорит "ну ок, но только это деприкейтед, атата!"

ну "тейлор так решил" тоже имеет место быть например абсолютно непонятное решение навязывать мне свой jetstream

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

LiveWire и Иннерция напоминают какой-то оверкильный кастыль Типа монолитное приложение, но с реактивностью Ну прям пахнет же писюнами

Вообще в ларавел очень мало делается вещей "Просто потому что Тейлор так хочет", ты меньше чатики Российские читай где каждый второй - бог программирования и вот он бы, вот он бы точно написал бы идеальный фреймворк

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

LiveWire и Иннерция напоминают какой-то оверкильный кастыль Типа монолитное приложение, но с реактивностью Ну прям пахнет же писюнами

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

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

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

В ру комьюнити Лары тоже принято обсирать решения Тейлора, откуда видимо и понес свое мнение оратор выше, он считает что достаточно квалифицирован чтобы судить решения других хотя до конца даже не понимает в чем преимущества колбэков при вызове джобов

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

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

Да я вообще про ру комьюнити, просто горит, но называть что - то говном не разобравшись почему так - как минимум странно

вроде слово "говно" я не видел)

Вот и я о том же

а про анонимки ваня сказал еще когда я в диалоге был

Он выше сказал что кэшировать джоб это пиздец)

Ай, ща найду

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

Вот