Автостопом по граблям: асинхронное лимитирование запросов в Python

[naquad]

С очередью - это оно кмк. Всё остальное - слишком. Как вариант: небольшой класс, который сразу отдаёт future клиентскому коду, а внутри его worker обрабатывает запрос. AsyncioLimiter можно и на банальный sleep заменить, довесить condition, чтобы если один worker получил 429, то флаг + sleep и продолжаем. Но это уже для пуристов, кто зависимости не любит.

[Adgh]

Хорошая обзорная статья - всё сжато и по делу. Вот только без обработки исключений / ошибок, access / refresh токенов, ретрая, журналирования, расчета IO-метрик... до production ready всё равно ещё больше половины пути. Что удивительно - сценарий частый / проблема общая, каждый пишет свой велосипед, но так никто и не взялся за универсальный "комбайн"

[mityukov]

Самое стремное, что когда гуглишь проблему - основная масса ответов про rate limiting входящих запросов. Но там лишние просто отбрасываются, а надо чтобы ждали. А ещё хочется сохранить очередность (FIFO)

[dyadyaSerezha]

Все хорошо, только почему время обработки запроса вы называете latency? Это не задержка ни разу. Тщательнее)

[it-infinite]

Это просто хрестоматийный пример "Эффекта Даннинга-Крюгера" в действии.. 😁

Не хочу обидеть автора, но если бы хотя бы почитали доку, или даде спросили у ИИ, ответ был бы сразу и решение в пару строк.. 😁

Поиск в интернете это хорошо, но искать надо то, о чем не говориться в документации.. 😁 Есть готовые решения, срока кода и все работает.. Гуглите. 😁

[maslievilya1]

Подскажите пожалуйста, какое решение вы имеете в виду?