Спасибо, так commands же и есть репо? Я думал, что в commands отходят методы сохранения и методы поиска для последующего измненения в юзкейсе. А в quieries всё, что с JOIN, которое возвращает DTO для удобного отображения.
Михаил Р., не совсем. Скрипт я написал, все работало хорошо. После блокировки ТГ надо было подключить прокси. Я подключил обычный socks5. В результате в России скрипт ловит таймаут с прокси, а без прокси работает нормально (если стоит впн на пк запускающего человека). А вне России что с прокси, что без прокси все работает нормально.
Refguser, так я стараюсь отвечать на все вопросы. Могу еще Burpsuite запустить, но это толку мало даст, наверное. Из-за этих блокировок приходится на кофейной гуще гадать
Михаил Р., прошу прощения, не знаю, какую информацию дать, чтобы помочь с решением.
Прокси, при запуске из России, работают в веб версии, в десктоп версии и в мобильном приложении, но не работают с telegram api.
Точно такое же прокси работает вне России на всех платформах и при любом виде использования.
Попытался поставить timeout на 60 секунд - всеравно не работает. При использовании прокси через openvpn в России оно подключается и работает медленно, но работает.
Everything_is_bad, я видел, что не прелесть. Раз таких проблем нет, то можно попробовать. Но мне бы сейчас определиться, делать ли отдельный воркер. Плюсов пока я найти не могу, по сравнению со слиянием в один процесс
Everything_is_bad, спасибо, почитал, действительно полноценный брокер. О taskiq слышал много плохого. Остался последний вопрос - какие плюсы есть у отдельного воркера по сравнению с такой же функцией, но в том же процессе, что и основное приложение?
Everything_is_bad, если редис упадет, то все данные сотрутся. Даже при rdb не будет полного at least once. А если ивенты будет хранить воркер, то воркер сам может упасть и потерять часть данных. Также, какие плюсы у отдельного воркера по сравнению с такой же функцией в том же процессе, что и fastapi/основное приложение?
Everything_is_bad, тоесть схема работы такая:
В транзакции добавляем ивент в outbox таблицу.
Отдельный воркер проверяет таблицу, запускает нужные для ивентов функции, следит за ретраями. Если это то, что он может выполнить сам (удаление файла из s3), то делает это. А если не может этого сделать (вебсокеты), то отправляет сообщение через pub/sub в главное приложение, которое через менеджер вебсокетов передает сообщение.
Верно?
Everything_is_bad, я неправильно выразился. Под атомарностью я имел ввиду "сделать пару независимых ретраев". Спасибо за идею с редисом, но как мне передавать объекты вебсокетов?
Полной атомарности достичь очень трудно, так что этот outbox я рассматривал как обработчик ретраев и фильтратор для неудачных вызовов (если после х ретраев всеравно неудача). Я бы сделал pub/sub, но у меня вебсокеты, которые непонятно как передавать в json. Они же живут в одном процессе. А делать пинг-понг из запросов как-то странно.