Где правильно выполнять проверку try/catch для внешних api в Laravel?

verygoodboy, но это не серебрянная пуля - то есть не решение на все времена и все нравы

Где правильно выполнять проверку try/catch для внешних api в Laravel?

verygoodboy, try catch должен быть в сервисах - что бы вы могли выбросить дальше не просто RequestException а свой подтип эксепшна который будет указывать на то какой именно сервис отвалился или чего еще случилось. Дальше в зависимости от того что мы хотим, если мы хотим тупо вьюху вывести - можете у этого эксепшн захреначить метод render

Где правильно выполнять проверку try/catch для внешних api в Laravel?

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

Где правильно выполнять проверку try/catch для внешних api в Laravel?

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

Где правильно выполнять проверку try/catch для внешних api в Laravel?

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

Где правильно выполнять проверку try/catch для внешних api в Laravel?

verygoodboy, Ну сильное подозрение что вам скажут что ваш сервис который отвечает за работу с каким апи определенно должен отлавливать экспешн от коннекта и выбрасывать свой эксепшн - что бы работать уже с SiteApiRequestException - а не просто с RequestException которая не пойми с какого сервиса прилетело. И это вам скажут не только ларавельщики.

Почему возникает утечка памяти в php-fmp?

Vitsliputsli,

Автор пришел не с этим, а с "Но что-то мне подсказывает, что данную задачу можно решить куда проще и наверняка она уже давно решена"

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

Сравнить можно вообще что угодно, главное какие выводы сделать.

Вывод блин простой. С массивами в пхп надо быть осторожнее. Они жрут много памяти. По-моему это очевидно.

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

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

З.Ы. Предлагаю сойтись на простом. Давайте вообразим что я злобный пхпфоб сказал что "пхп дерьмо", вы бестрашно ринулись и защитили его от меня, ввергнув в гиену огненую за сии крамольные слова. Вас наградили золотым костылем и золотым велосипедом, назвали принцем пхп (или принцессой - я толерантный) и вы укатили на этом велосипеде в закат, грозя окружающим костылем и крича "Так будет с каждым"? Мне честно говоря лениво рассуждать о том что констатация минусов той или иной реализации не является наездом на реализацию.

PHP не видит директорию?

Сергей Миллер, создать файл который будет содержать только

<?php
// Show all information, defaults to INFO_ALL
phpinfo();

обратиться к нему при помощи браузера, вывод добавить к вашему запросу - только не скриншотом

PHP не видит директорию?

Сергей Миллер,
Ну внезапно ровно то о чем я написал - open_basedir

PHP не видит директорию?

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

PHP не видит директорию?

https://www.php.net/manual/en/ini.core.php#ini.ope... ?

phpinfo выведите

Почему возникает утечка памяти в php-fmp?

Vitsliputsli,

Читал, только вот автор и пришел с тем

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

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

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

TG web hook & Let Encrypt?

Игорь, ну а где тут обращение к bot.php?

TG web hook & Let Encrypt?

Игорь, ну здесь нет никакого сообщения об ошибке. мои поздравления, должно работать

TG web hook & Let Encrypt?

Игорь, ну значит телеграм лезет не на тот адрес. или еще чего - Wrong response from the webhook: 500 Internal Server Error строка четко и конкретно говорит что происходит. То что тот адрес по которому вы заходите отдает 200 в любом случае - это сообщение отменить не может. Откройте логи вебсервера и посмотрите что вам прилетает от ТГ и по какому адресу.

TG web hook & Let Encrypt?

Нет. Это строка не говорит о том что тг не принимает сертификат. А вот строка « Wrong response from the webhook: 500» говорит о том что ваш скрипт падает к хренам при попытке его вызвать

Как обеспечить идемпотентность запросов к API?

Andrey Dontsov,

Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом.

Да не вопрос. Надеюсь нырнув ко мне на уровень, вам удалось понять и запомнить когда стоит использовать идемпотентность, а когда она будет бесполезной тратой времени и ресурсов, поняли что не надо тащить в рот все что дают вам в руки, хочется верить что таки сходили по ссылке и поняли как генерить UUID на основе данных, и самое главное осознали что на вопрос "зачем вам это", нужно обьяснять контекст задачи, требования, а не пытаться сыпать терминами. Так сказать ныряйте чаще - может станете программистом.

К сантехнику прикрепили практиканта. Вызывают на выезд. Приезжают. Канализационный люк. Из него течет дерьмо. Сантехник подходит к люку и ныряет.
Через минуту выныривает, кричит:
- Ключ на 19.
Снова ныряет. Через полминуты выныривает:
- Прокладку No.6.
Опять ныряет. Выныривает:
- Ключ на 26.
Ныряет. Через минуту выныривает. Выходит, отряхивается и закуривает. Сел, отдышался и говорит практиканту:
- Вот так!.. Учись, студент! А то так и будешь всю жизнь ключи подавать...

Почему возникает утечка памяти в php-fmp?

Vitsliputsli,

учитывая что в той теме упорно не читали что вам пишут, игнорировали собственно вопрос автора

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

"массив в пхп вещь тяжелая" подразумевает, что есть лучшие реализации вне пхп

Лучшее в чем? В функционале или в количестве памяти на реализацию функционала? И еще раз если брать какой нибудь статический массив на сях - никаких накладных расходов по памяти. Но вагон минусов по функционалу. Массив в php - хеш таблица, с вагоном плюсов по функционалу, но вагон оверхеда по памяти. Создаете массив в php - надо понимать что в памяти будет валяться не только переменная а вагон всего. Ну это и есть тяжесть. В чем так сказать ваши претензии? Я написал что-то неверное? Да вродь нет. Вам нравится реализация массивов в PHP? Мне тоже - но это не отменяет того что там вагон оверхеда по памяти и надо понимать что $arr = [1]; у вас памяти займется несколько больше нежели 1. Вы просто испытываете боль от упоминания оверхеда? ну примите нурофен

Как обеспечить идемпотентность запросов к API?

Andrey Dontsov,

Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.

Нееее. Вы не в состоянии обьяснить контекст задачи.

При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.

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

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

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

Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?

Я бы наверное отсоветовал использовать функцию crypt, ибо она здесь избыточна, не генерирует строку достаточного размера что будет неудобно, если целью будет получение UUID, как того советуют в доке. И вам стоит поводить мышкой по ссылкам что содержится в моих комментариях там будет библиотека генерации UUID v3, v5 на основе алгоритмов md5 и sha-1, которые для этого и должны использоваться по спецификации, вродь как, и на основе данных которые позволят вам автоматом получать уникальный UUID если содержимое заказа поменялись. Но c вашим подходом похоже что угодно прокатит.
Правда ответ к номеру договора никакого отношения не имеет. :)

Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.

В блудняк втянули себя вы. Если бы вы остановились бы и задумались банально на ПЕРВОМ вопросе, - то было бы 2 варианта продолжения. Вы бы поняли что имодентность и возня с сохранением вам не нужна, можно было бы без нее, либо вы описали такой контекст задачи что я бы понял что вам она нужна, и сразу бы предложил вариант генерации UUID на основе данных.
Но вы с какого то перепугу решили что на той стороне провода сидит человек который не знает что такое идемпотентность, и решили обьяснять базовые вещи, приводить статьи которые к вашей задаче отношения не имеют, и нести какую то ахинею в какой-то нелепой попытке не признать что блин просто не дочитал, блин просто не задумался, блин просто решил повыпендриваться - получился блудняк и полная веселуха.

З.Ы. Лет то сколько? Если не секрет. Как мне маме то теперь возражать?

Почему возникает утечка памяти в php-fmp?

Vitsliputsli, Массив через хеш таблицы как в пхп - прекрасен по скорости работы - O(1), и по функционалу - запихивай что хочешь и сколько хочешь. Ценой за это превосходство над массивом который тупо выделенная память со смещением - является дополнительный расход памяти. Ничто не дается бесплатно и реализация в пхп тяжелая ПО ПАМЯТИ. Так как разговор шел именно про ПАМЯТЬ, то я это и сказал.

З.Ы. Помнится вы уже как то пытались защищать пхп от моих слов в теме про обработку задач, может не пойдем на те же грабли? :) Я так если чего не хейтер пхп - я на нем пишу.