Когда только начал смотреть видео, подумал, что логику с отправкой email вынесут вообще в отдельное выполнение, как с Celery. А тут оказалось в другом смысл. Не слышал о такой штуке раньше, возьму на заметку. Действительно удобно и абстрактно)
Можно все собирать в словаре data, либо через args и kwargs, а оттуда уже брать что нужно. Но вообще лучше сделать так чтобы сам event в себе нес все нужные данные
Ещё как вариант NamedTuple/dataclass. По сути это какой-то DTO между эвентами с известным интерфейсом (например, для сравнения: какой интерфейс у словаря?). Попробуйте так Ещё можно сделать в БД новую табличку UserRegisteredEvents, а в dipatch просто передавать id эвента. Тогда вы сможете сделать soft realtime на очередях и так далее, но это уже фантазия...
Explicit is better than implicit! А тут получается что мы можем оставить кучу пустых вызовов в коде без ошибок, но при этом чтоб удостовериться что они действительно "пустые" нужно чуть ли не в дебаггере неймспейсы просматривать
Кратко, ясно и по делу. Спасибо!
Спасибо большое за видео и качественный разбор . Продолжайте в том же духе !
Ещё слышал про команды в связке с евент драйвен, есть ли они здесь?
где-то я уже видел такое руководство
Найс разбор. Качественные пояснения
callable это функция для проверки что объект Callable.
В тайпхинтингах это то же самое что сделать вместо Any - any
Когда только начал смотреть видео, подумал, что логику с отправкой email вынесут вообще в отдельное выполнение, как с Celery. А тут оказалось в другом смысл. Не слышал о такой штуке раньше, возьму на заметку. Действительно удобно и абстрактно)
Название видео действительно наводит на мысль, что тут будет нечто масштабное, хотя по сути разобран паттерн Observer.
А где этот main с register handler будет в фастапи например? А в ручках апи, юз кейсах?
А как передать в dispatch различные аргументы для разных функций?
Можно все собирать в словаре data, либо через args и kwargs, а оттуда уже брать что нужно. Но вообще лучше сделать так чтобы сам event в себе нес все нужные данные
@@PythononPapyrusRU Спасибо за обратную связь, разобрался
От вашей задачи зависит, можно доп данные так передавать reg_hendlers("name_hend", func, args) и словарь расширить с функцие и аргументами.
Ещё как вариант NamedTuple/dataclass. По сути это какой-то DTO между эвентами с известным интерфейсом (например, для сравнения: какой интерфейс у словаря?). Попробуйте так
Ещё можно сделать в БД новую табличку UserRegisteredEvents, а в dipatch просто передавать id эвента. Тогда вы сможете сделать soft realtime на очередях и так далее, но это уже фантазия...
Explicit is better than implicit!
А тут получается что мы можем оставить кучу пустых вызовов в коде без ошибок, но при этом чтоб удостовериться что они действительно "пустые" нужно чуть ли не в дебаггере неймспейсы просматривать
Я про это в конце сказал
Прикольно, но почему словарь, а не класс "event_register" или events.register? Тогда и параметры можно будет нормально передавать.
Потому что это простой пример реализации ивентов, для учебного примера усложнения ни к чему
@@YntymakPlay имхо, нужно сразу правильный пример показывать. Говорю как человек, который проходил все это.