Comments 24
По моему django-admin действительно крутой проект, возможно это самая лучшая часть django (еще мне нравятся миграции). И странно, но до сих пор нет вменяемых альтернатив (например для той же FastAPI), что бы можно так же легко и быстро создать админку. Всему конечно своя цена, и с ростом сложности, обходить костыли Django становится все сложнее. Но в чат админке ограничений намного больше
С одной стороны, да. С другой -- простой табличный вывод с шаблонизатором и фильтром реализуется за несколько часов. Джанга же нервов потреплет в сумме больше, чем на несколько часов.
Больше чем несколько часов - Это только если разработчик не знает django.contrib.admin ну и иже с ними django.utils, Django.views и в общем Django.contrib
Я заточился именно на django.contrib.admin мои доклады по этой части Джанго есть на Ютубе, будет доклад на Django con EU 22, и Django con US 22. Мне видно, что автор статьи не очень понимает Django. Почти все, что в шаблонах, в моей команде мы правим через код. Шаблоны со времён правки ошибок в inlines.html для nested inline мы не трогаем. Дизайнер иногда касается css. Я к тому, что сложности в кастомизации админки только у тех, кто не понял как она работает. А таких, увы, очень много.
Подскажите, пожалуйста, что значит "все, что в шаблонах, … мы правим через код"? Просто сейчас работаю с Django по его назначению, и поэтому был бы признателен за пример таких правок.
Привет. Попробуй что-то увидеть на слайдах презентации с python con 2021 тут,
Либо смотри репозиторий тут. Там есть пример, как влезть в админский кусочек шаблона,для добавления кнопки слева от верхней левой кнопки действия.
Общая идея - в шаблонах админки много вставок админ тегов, суб шаблонов поключаемых через include, и блоков. Каждый тег и шабон можно переопределить. однострочные шаблоны для виджетов можно генерить на лету, если надо что-то поправить. Тоже относится к рендеру блоков, когда мы можем повлиять на рендер того или иного блока отслеживая его рендер, например, по имени( {% block 'name' %}). В итоге получается, что можно вклиниться куда угодно на моменте render на уровне python.
Согласен, я и указал в "плюсах", что Django-admin — классная вещь с точки зрения скорости развертывания. Но там первое слово — Django, и тащить весь фреймворк в проект просто из-за админки — решение почти всегда не лучшее.
Кстати про FastAPI: я начал следить за проектом: https://github.com/fastapi-admin/fastapi-admin. Похоже, потихоньку развиваются альтернативы django-admin.
Думаю вопрос поддержки алхимии для fastapi-admin вопрос времени.
Я один из тех, кто использует aiogram + django admin and migration для MVP.
По минусам в статье:
Изначальная несовместимость фреймворков – какая разница, когда aiogram и django все равно крутится каждый в своем docker и лежит в разных репах? Они выполняет разные функции и django может быть удален одной кнопкой, когда придет время для его удаления?
Мы же не говорим что PostgeSQL и Redis несовместимые технологии - просто выполняют разные задачи.
Из плюсов - все написано на Python, нам не нужен frontend разработчик.Django ORM – У нас что, 1000 админов? Зачем нам асинхронная ORM в админке? Понятно, что пользователей бота может быть несколько десятков тысяч + сам интерфейс предполагает быстрое взаимодействие - там нужна скорость, а для админки зачем скорость?
Из пушки по воробьям – no comments. Не нужны forms, tests, views and caches - не используй, не нужны applications - положи все в одну папку. Джанго можно использовать не только как написано в Tutorial, а просто сделать проект на 5-7 файлов в одной папке, если структура БД небольшая.
Дополнительный плюс:
Переодические задачи – если нужно раз в час что-то обновить, то periodiq + dramatiq отлично дружат с Django ORM и так же экономит время и деньги.
Из реальных минусов django admin не указан самый главный: отсутствие нормальной кастомизации.
В реальной жизни первое время встречались кейсы, когда клиент не понимал почему я сделал такую красивую админку быстро, но не могу "перекрасить всего лишь кнопку".
Теперь я говорю так: админку даю вам в подарок as-is и мы ее внешне не переделываем. Как только функционал бота будет более-менее стабилизирован, бизнес модель протестирована, то выделяем бюджет и делаем нормальную панель на FastAPI + Vue/Flutter/подставьте_свою_технологию с любым дизайном. Такой подход уже работает нормально.
Отличное дополнение. А почему бы не выкатывать сразу на стадии MVP нормальную админку под FastAPI? По требованиям заказчиков, какие я встречал, они все ± на одно лицо, и можно себе накидать базовый универсальный шаблон с UI на том же Vue.
А почему бы не выкатывать сразу на стадии MVP нормальную админку под FastAPI?
Потому что ее еще нужно сделать, потратить некое количество времени (быстро и функционально вроде невозможно), а тут уже готовое.
Как написали выше, админку можно прикрутить потом, когда все будет стабильно
По требованиям заказчиков, какие я встречал, они все ± на одно лицо, и можно себе накидать базовый универсальный шаблон с UI на том же Vue
Тогда, почему до сих пор не накидал и не предлагаешь заказчикам?
А можно вопрос - в докер с aiogram для взаимодействия с БД что используете, Джанго ORM или что-то асинхронное?
Просто Джанго орм же вроде синхронный полностью, получается блокируется весь луп пока ОРМ не выполнит запрос объектов. Или используете пул из синхронных экзекьютеров для этого?
Сам столкнулся с такой проблемой и пока просто выбрал синхронный фреймворк для телеграмм, чтобы дружить с Джанкой, ни такие там рпс на ботов чтобы ассинхрогщину держать обычно.
А чем aiogram лучше чем python-telegram-bot? Из-за того что python-telegram-bot пока только переезжает на asyncio?
1) Aiogram — полноценный фреймворк, а не просто обертка над API Telegram. Он очень похож на аналогичные backend-фреймворки. Тут из коробки FSM (Finite State Machine — она же машина состояний), фильтры, миддлвари. Aiogram — честно-асинхронный, т.к. под капотом aiohttp, asyncio.
2) Комьюнити.
2.1) Оно просто самое большое и активное. Все проблемы решили до Вас, и в тех же Telegram-чатах есть ответы на большинство из интересующих вас вопросов. А если нет, то Вам на них скорее всего ответят.
2.2) Реализовано большое количество вспомогательных классных библиотек: упомянутый aiogram-dialog, fluentogram (обертка над встроенным механизмом i18n). Есть куча готовых темплейтов и примеров ботов на все случаи жизни со всеми "комбинациями" стеков.
3) Развитие фреймворка. Скоро релиз 3-ей версии (сейчас она в beta), в которой появятся роутеры, приятные фичи и наконец-то хорошая документация. Полный список отличий от текущей версии можете найти на официальном сайте (aiogram.dev).
4) Оперативные обновления с интеграцией новых версий BotAPI.
5) Он очень хорош с точки зрения наличия документ-строк (докстрингов), подсказок типов (тайпхинтов), без которых программировать на питоне уже дискомфортно.
Спасибо за подробный ответ! Думаю попробовать aiogram, как раз надо небольшого бота написать.
python-telegram-bot тоже фреймворк. Полноценной FSM в нем нет, но какое-то подобие в виде ConversationHandler есть. И диалог с помощью него в принципе можно написать. Я как раз почему-то думал что aiogram небольшая библиотечка, основной плюс которой, то что он написан на asyncio. A python-telegram-bot здоровый фреймворк типа джанги, где есть куча всего
Исправить комментарий выше не могу по сроку давности.
Ошибся по поводу библиотеки Fluentogram: это не обертка над встроенным в Aiogram механизмом i18n, а альтернатива, построенная на Mozilla Project Fluent.
А почему не разнести просто эту историю на 2 микросервиса. Джанго в одном, классический бэк. Айограм в другом, по факту и бай дезайн - фронтенд.
Есть даже проект в закрамах гитхаба с таким подходом и работает вполне сносно.
А почему бы просто не поднять сервис на DRF и путь aiogram по API работает с джангой. Таким образом у Вас будет разделена отвественность. aiogram взаимодействие с пользователем, логика в API. Более того методы API можно будет переиспользовать, если проект будет развиваться и понадовится нормальный фронт.
Глянул шаблоны — нигде толком нет тестов. Неужели боты тестируются вручную?
вот специально зашел минус влепить.
У меня аж подгорает. Откуда мать его этот фап на миллисекунды. За все годы разработки у меня на первом месте всегда была функциональность и акцент на бизнес-логике. И джанго с этим прекрасно справляется. Зачем тачищить асинхронность и алхимию чтобы сэкономить 20 милисекунд? А не знаю в каком мире вы живете, а в моем заказчику куда важнее бизнес функционал, и проще подбросить еще одну машину в облаке, нежели занимать тюнингом кода.
Хотите скорости, делайте на go. python и django не про скорость выполнения, а про скорость разработки и качество.
Aiogram + Django — бич индустрии чат-ботов