Hot-reload. Наверное, самый важный DX функционал в любом фреймворке. До текущего дня, уверен, вы перезапускали аж всего бота, чтобы увидеть минорные изменения кода.
Я настолько привык что оно во многих случаях глючит или не работает, что просто не юзаю нигде.
RBAC (Role Based Access Control) это классика.
классика, которой почти всегда не хватает. Что насчет ReBAC? В целом я не очень люблю, когда логику проверки прав переносят из БЛ в фреймворк.
Диалоги использовать в высоконагруженных ботах не рекомендуется, в связи с тем, что они используют asyncio.Future и удерживают пул сессий.
Проблема не только в нагрузке (полагаю речь про горизонтальное масштабирование), но и в том что при рестарте бота эта информация будет потеряна.
Интерфейс абстрактной фабрики в вашем случае - требование наличие метода create. Он имеет смысл, потому что мы можем сказать "вот сюда передайте любой объект с методом create". А как вы собираетесь описывать интерфейс для фабричного метода у меня вызывает вопрос, ведь в основном фабричный метод используется внутри того же класса (см. паттерн шаблонный метод)
Sorry, перечитал внимательно, фабричные методы на месте, но как-то впепремешку с фабриками. Вы там ещё и интерфейс для фабричных методов предлагаете и промпт у вас по запросу фабричного метода абстрактную фабрику выдал.
По моему личному опыту ИИ-тексты отличаются поразительно низким количеством полезной информации на единицу контента. Бывает читаешь, читаешь, вроде интересно, а что прочитал - непонятно. Три раза одну мысль перевернули по разному, досыпали несвязанных фактов, пропустили логические цепочки, никаких выводов или деталей, позволяющих эти выводы сделать самим. Конечно, так же пишут и некоторые копирайтеры, но это не в плюс к ним.
exec-кодогенерация не меняет подход к созданию объектов, она позволяет делать инайлнинг, вырезание веток и разворачивание циклов.
Условно, до кодгена был такой код
res = cls(*(container.get(d) for d in deps))
if cached:
cache[cls] = res
то, имея cached=False, а deps=[int, str, A], мы можем вырезать иф, убрать распаковку и сгенерировать
res = cls(container.get(int), container.get(str), container.get(A))
Резвол асинк зависимостей в dishka есть, то я бы рекомендовал с этим быть осторожнее. С большой вероятностью (вероятно не всегда), если вы делает async-вызов при создании ресурса, вы смешиваете бизнес логику и просто получение зависимости. При этом я понимаю, что избежать async вызова при финализации ресурса будет сложнее
А, ну я всегда рассматривал transient как "костыль", которым никто не пользуется, ведь scoped объекты ничем не хуже, зато точно можно переиспользовать в скоупе. Надо будет повнимательнее посмотреть на ваш код, вызвана скорость отсутствием фич или конкретными механиками, уж действительно быстро вышло
Я в dishka генерирую код на python и через exec преобразую. Это позволяет вырезать всякие ветки и разворачивать циклы. Например, так нет огранения на количество параметров функции (я вижу у вас отдельно расписаны варианта до 4)
По моему опыту, компиляция всего графа в одну функцию не очень хорошо ложится на кэширование/обработку ошибок и прочее. Функции становятся гигантскими, код грязным и прочее оно тормозит уже на этом этапе.
Я компилирую каждую обертку над конструктором, не весь граф. Это всё ещё работает очень быстро и не лишает вас других фич, которых можно напридумывать миллион.
Вижу что вы сравниваете скорость с wireup и dependency-injector, а с dishka не пробовали?
Не работает, если в приложении предполагается конкурентное использование БД. А это часто деталь реализации, которая если есть хотя бы в одном месте приложения, то значит может встретиться где угодно.
На всякий случай, я тут рылся по источникам и пришел к выводу что разделение конкурентности и параллелизма именно таким образом - это идея Роба Пайка и больше нигде не встречалась раньше. Тот же Таненбаум вполне юзает их как синонимы. Когда я учился в школе, использовались термины "истинная параллельность" и "псеводпараллельность" для тех случаев когда важно было уточнить эту разницу.
Ну во-первых, он упоминался в посте и какое-то ощутимое количество юзеров всё таки есть. Во-вторых, 40 issue, из которых большая часть - идеи по развитию - это не очень большое число. В третьих, проекту несколько лет, он давно прошел стадию активного наращивания фич, че там коммитить каждый день? В четвертых, кажется для кейса комментатора выше как раз неплохо подошло бы
Я настолько привык что оно во многих случаях глючит или не работает, что просто не юзаю нигде.
классика, которой почти всегда не хватает. Что насчет ReBAC? В целом я не очень люблю, когда логику проверки прав переносят из БЛ в фреймворк.
Проблема не только в нагрузке (полагаю речь про горизонтальное масштабирование), но и в том что при рестарте бота эта информация будет потеряна.
Рассматривали ли вы
aiogram_dialogв этом месте?Да, я не понимаю как вы собираетесь использовать интерфейс при реализации паттерна фабричный метод
Интерфейс абстрактной фабрики в вашем случае - требование наличие метода
create. Он имеет смысл, потому что мы можем сказать "вот сюда передайте любой объект с методом create". А как вы собираетесь описывать интерфейс для фабричного метода у меня вызывает вопрос, ведь в основном фабричный метод используется внутри того же класса (см. паттерн шаблонный метод)Sorry, перечитал внимательно, фабричные методы на месте, но как-то впепремешку с фабриками. Вы там ещё и интерфейс для фабричных методов предлагаете и промпт у вас по запросу фабричного метода абстрактную фабрику выдал.
Я может невнимательно читал, но не вижу в статье фабричных методов. Везде отдельный класс-фабрика
Но ведь Factory и Factory Method - это два разных паттерна
Взять растения с разной хиральностью и вот борьба за солнечный свет
Пол Андерсон "Звездный торговец"
По моему личному опыту ИИ-тексты отличаются поразительно низким количеством полезной информации на единицу контента. Бывает читаешь, читаешь, вроде интересно, а что прочитал - непонятно. Три раза одну мысль перевернули по разному, досыпали несвязанных фактов, пропустили логические цепочки, никаких выводов или деталей, позволяющих эти выводы сделать самим. Конечно, так же пишут и некоторые копирайтеры, но это не в плюс к ним.
exec-кодогенерация не меняет подход к созданию объектов, она позволяет делать инайлнинг, вырезание веток и разворачивание циклов.
Условно, до кодгена был такой код
то, имея
cached=False, аdeps=[int, str, A], мы можем вырезать иф, убрать распаковку и сгенерироватьРезвол асинк зависимостей в dishka есть, то я бы рекомендовал с этим быть осторожнее. С большой вероятностью (вероятно не всегда), если вы делает async-вызов при создании ресурса, вы смешиваете бизнес логику и просто получение зависимости. При этом я понимаю, что избежать async вызова при финализации ресурса будет сложнее
Асинкио таску можно потом когда-нибудь заэвейтить и получить результат, а тут.. увы
А, ну я всегда рассматривал transient как "костыль", которым никто не пользуется, ведь scoped объекты ничем не хуже, зато точно можно переиспользовать в скоупе. Надо будет повнимательнее посмотреть на ваш код, вызвана скорость отсутствием фич или конкретными механиками, уж действительно быстро вышло
Я в dishka генерирую код на python и через exec преобразую. Это позволяет вырезать всякие ветки и разворачивать циклы. Например, так нет огранения на количество параметров функции (я вижу у вас отдельно расписаны варианта до 4)
По моему опыту, компиляция всего графа в одну функцию не очень хорошо ложится на кэширование/обработку ошибок и прочее. Функции становятся гигантскими, код грязным и прочее оно тормозит уже на этом этапе.
Я компилирую каждую обертку над конструктором, не весь граф. Это всё ещё работает очень быстро и не лишает вас других фич, которых можно напридумывать миллион.
Вижу что вы сравниваете скорость с wireup и dependency-injector, а с dishka не пробовали?
а потом думаешь - а как теперь подождать после запуска, как получить её результат? а как узнать что функция упала с паникой?
Не работает, если в приложении предполагается конкурентное использование БД. А это часто деталь реализации, которая если есть хотя бы в одном месте приложения, то значит может встретиться где угодно.
Как насчет drop database + create database .. TEMPLATE? может быть быстрее транкейта
На всякий случай, я тут рылся по источникам и пришел к выводу что разделение конкурентности и параллелизма именно таким образом - это идея Роба Пайка и больше нигде не встречалась раньше. Тот же Таненбаум вполне юзает их как синонимы. Когда я учился в школе, использовались термины "истинная параллельность" и "псеводпараллельность" для тех случаев когда важно было уточнить эту разницу.
Ну кстати, а не сталкивались с отличиями поведения того же postgresql/mysql между версиями?
Стало интересно, а код где храните?
Ну во-первых, он упоминался в посте и какое-то ощутимое количество юзеров всё таки есть. Во-вторых, 40 issue, из которых большая часть - идеи по развитию - это не очень большое число. В третьих, проекту несколько лет, он давно прошел стадию активного наращивания фич, че там коммитить каждый день? В четвертых, кажется для кейса комментатора выше как раз неплохо подошло бы