Comments 12
Я буду рад услышать любые предложения для расширения функционала Raito. Если вам чего-то не хватало (или мешало) при написании ботов, расскажите об этом здесь)
Hot-reload. Наверное, самый важный DX функционал в любом фреймворке. До текущего дня, уверен, вы перезапускали аж всего бота, чтобы увидеть минорные изменения кода.
Я настолько привык что оно во многих случаях глючит или не работает, что просто не юзаю нигде.
RBAC (Role Based Access Control) это классика.
классика, которой почти всегда не хватает. Что насчет ReBAC? В целом я не очень люблю, когда логику проверки прав переносят из БЛ в фреймворк.
Диалоги использовать в высоконагруженных ботах не рекомендуется, в связи с тем, что они используют
asyncio.Futureи удерживают пул сессий.
Проблема не только в нагрузке (полагаю речь про горизонтальное масштабирование), но и в том что при рестарте бота эта информация будет потеряна.
Рассматривали ли вы aiogram_dialog в этом месте?
Я настолько привык что оно во многих случаях глючит или не работает, что просто не юзаю нигде.
Согласен, я тоже сталкивался с багами, вызванными hot reload, поэтому в Raito решил ограничиться только папкой хэндлеров. Watchdog не следит за всем проектом, т.к. у всех разный подход к разработке и перезагрузка модуля может вызвать побочные эффекты. А хэндлеры перезагружать в какой-то степени безопасно, с hot-reload намного проще править text/caption в отправляемых сообщениях и хотфиксить, это основная причина перезапусков бота - минорные изменения хэндлеров.
классика, которой почти всегда не хватает. Что насчет ReBAC? В целом я не очень люблю, когда логику проверки прав переносят из БЛ в фреймворк.
На самом деле, я долго колебался на счет внедрения rbac в библиотеку. С одной стороны это бизнес-слой, а с другой, я даю возможность полностью им управлять через интерфейсы.
В конечном счете решил добавить из-за двух фишек:
OR операции: в aiogram можно комбинировать фильтры (|&~), но чтобы подобное реализовать для ролей, нужно было покопаться в коде aiogram. И я уверен, не ВСЕМ бы разработчикам пришла такая идея в голову, что уж говорить про реализацию. Хотя, как по мне, это самое комфортное использование ролей-фильтров из всех возможных.
Регистрация команд: возможно, это первостепенная причина; из-за скрытия хэндлеров под ролями, они не должны отображаться в слэш-меню у обычных пользователей, но должны показываться у привилегированных. В статья я уже «хвастался», что благодаря парсингу всех хэндлеров проекта, Raito может автоматически регистрировать
bot.set_my_commands, только я забыл упомянуть, что он их еще регистрирует группируя по ролям.
Что касается использования, я ничем не обязываю, можно проигнорировать этот модуль библиотеки и использовать свою реализацию.
Проблема не только в нагрузке (полагаю речь про горизонтальное масштабирование), но и в том что при рестарте бота эта информация будет потеряна.
Рассматривали ли вы aiogram_dialog в этом месте?
wait_for скорее экспериментальная фича со множеством побочных эффектов. Я строго не рекомендую ее использовать в серьезных ботах. Но тем не менее, мне очень нравится её простота, и я использую Диалоги в своих личных ботах, в связи с легкостью разработки :)
Касательно aiogram_dialog, да, я изучал Вашу библиотеку, мне она тоже нравится, очень качественная)
И я её в секции Пагинация кстати тоже подразумевал, как «одну из», использующую хранилище (безусловно, в случае aiogram_dialog это оправданно, и конечно в этом нет ничего плохого); но я хотел предложить сообществу упрощенные пагинаторы, использующие самый классический способ хранения информации, чтобы разработчики просто использовали raito.paginate и router.on_paginate и не морочили себе голову пагинациями, а могли сфокусироваться на функционале.
В любом случае, выбор зависит от кейса, вкусов и желания.
Если бы вы после `Мы все используем aiogram, это по праву лучшая API обертка из существующих.` дописали `ИМХО`, статью было бы читать немного проще.
Понравилось, что библиотека не пытается заменить aiogram, а именно дополняет его. Часто подобные проекты начинают постепенно "затягивать" всё в себя и через год превращаются в отдельный фреймворк с несовместимым API. Если получится удержать именно формат DX-плагина — это, на мой взгляд, самый удачный путь.
Самая большая опасность таких библиотек — желание собрать вообще всё. Сегодня hot reload и пагинация, завтра ORM, DI, планировщик задач и свой конфиг. Интересно, где автор сам для себя проводит границу, чтобы Raito не превратился в очередной "framework over framework".
Спасибо за приятные слова)
Важно еще понимать, что чем больше функционала, тем сложнее поддерживать проект, и тем выше риск заиметь множество багов.
Я стараюсь придерживаться той концепции, когда мы пичкаем библиотеку легковесными(!) и нативными плагинами, которые могут понадобиться любому разработчику (от новичка, до опытного)
Конечно, до кастомной ORM или DI дело не дойдет.
Я надеюсь, если проект соберет достаточную аудиторию, мы сможем вместе выстроить правильный вектор развития и границы.
Всегда немного настораживает hot reload в Python-проектах. Пока проект маленький — магия. Потом начинаются singleton'ы, фоновые задачи, импорт побочными эффектами и выясняется, что полный рестарт был не таким уж плохим решением.
В проекте тестов нет.
Облегчи себе разработку ботов – Raito