Comments 8
Извините, но очень похоже на изобретение того, что есть в message-driven architecture. Всякие там «кафки», ActiveMQ и так далее.
И вообще, если у вас запрос «упал», то лучше разбираться почему это произошло, а не долбить в сервер n-раз.
на счет «кафки», ActiveMQ - я MQ систему не изобретал, как раз эта либа работает на очередях.
И вообще, если у вас запрос «упал», то лучше разбираться почему это произошло, а не долбить в сервер n-раз. - ситуации бывают разные, бывают ситуации когда сеть моргнула в микросервисах или допустим система на другой стороне висит (я отталкиваюсь от реального кейса когда интеграция при интеграции с другой системой на их стороне висела api) в таких ситуациях библиотека помогает, тут так же можно внутри ее обработать и ситуации падения, внутри прописать сценарий логирования и увидеть проблему, не обязательно просто долбить - можно и залогировать и разобраться
А то, что вы пошлете один запрос, потом другой и в итоге API обработает его дважды — это лучше? Как по мне это слабое решение. А вдруг нам важна целостность запросов?
Ладно, мы побеседовали, у нас с вами разные мнения и это хорошо.
Если это микросервисная архитектура, то retry нужен, чтобы api не обрабатывала один и тот же запрос несколько раз, можно ввести идентификатор и прикреплять его к запросу. При обработке другим сервисом проверять идентификатор на момент того, обрабатывался ли он ранее, если да, то скипать повторный запрос.
Звучит как transactional outbox паттерн
у http клиента от laravel есть метод retry который позволяет повторить запрос сколько угодно раз, а так же обрабатывать ошибку по необходимости, я думаю это подошло бы на случай когда "моргнула сеть"
Добавлю комментарий - temporal.io успешно работает и на мелких проектах, и без проблем на Rasberry Pi.
Она монструозна в плане фич, но большинство из них вам все равно придется писать самим.
Persistent-request библиотека для надежных запросов