Как стать автором
Обновить

Комментарии 18

Так и что с этим дальше делать? Как отправлять данные через бот? Как принимать данные и куда они попадут? Как асинхронщину включать?

С базой данных можно взаимодействовать через импортирование моделей Django. Там же можно создать модель Telegram пользователя и хранить их информацию. В одном из первых стартапов, я как-то писал декоратор который по ID Telegram пользователя в сообщении авторизовывал его связывая Telegram ID с его учетной записью в общей базе данных.

Так, что-то вы не ответили на вопросы, давайте по-порядку.
Бот нужен, чтобы:
1) передавать данные в телеграм.
Как вы это будете делать из вьюшек django, если у вас бот -- в команде, работающей отдельным потоком? Никак, значит, вы облажались.
Есть один обходной путь: вам придётся создавать на каждую отправку сообщения пользователю по записи в БД, и читать её из процесса с ботом. Тогда 5000 сообщений в секунду -- ваш предел, БД целиком забьётся. Но и 1000 сообщений в секунду уже будет много. И ещё будет поллинг сообщений из БД, а это задержки отправки и постоянная небольшая нагрузка на БД.
2) получать данные из телеграма.
Тут ок, работает.
Ну сделаем мы django.setup() из питон файла вместо того, чтобы сложить его в django management commands. Что же поменялось? А ничего не поменялось, спокойно можно использовать его, только надо помнить, что вызовы Django ORM -- синхронные, и надо ставить асинхронный драйвер БД и поменьше вызывать бизнес-логику из models.py / managers.py / где там она у вас лежит. А иначе больше 100 одновременных пользователей не вывезете в этом одном процессе. Ну, наверное, на ваших проектах больше и не нужно никогда, и все счастливы.

Хорошо, давайте попробую ответить на ваши вопросы по порядку)

1. Передавать данные в Telegram:
Само содержимое файлов Django приложения никак не обязывает разработчика использовать представления фреймворка в целях обработки сообщений и вызова команд. Напротив, в том же файле представлений можно прописать обработчики сообщений используя классы и функции библиотек которые будут возвращать результат в виде отправки сообщения или редактирования уже существующего (например для меню).

Во вторых, далеко не обязательно сохранять историю сообщений с пользователем ведь часто в этом нет необходимости, да и это противоречит главной политике самих чат ботов. По их изначальной задумке они должны вести частную переписку с пользователем и лишь обрабатывать запросы, а не хранить их. От того большой необходимости в постоянном редактировании базы данных нет.

Разве, что хранение пользователей и информации о них, но чтобы оптимизировать эту операцию можно применить хэш таблицы где формат ключ - значение идеально подойдет под Telegram ID пользователя и его запись в базе данных (для которой кстати Telegram ID можно использовать в роли первичного ключа).

2. Получать данные из Telegram:
Здесь отчасти соглашусь, Django не предоставляет полноценной поддержки асинхронного программирования из-за чего приходится прибегать к использованию сторонних библиотек.

С другой стороны Telegram боты не всегда имеют настолько большие нагрузки, от того в статье и было указано, что данный подход удобен лишь при разработке на скорость и относительно небольшой кодовой базе Telegram бота. Если ваша функциональность выходит за рамки предельной производительности данного подхода, то смело пишите отдельный проект и связывайте их любым известным вам способом.

Если у вас возникнут еще вопросы по поводу статьи или данные выше ответы не полностью покрывают ваш интерес, то пишите в комментарии, я обязательно отвечу)

Что-то вижу какой-то ответ в стиле чатгпт.

Вот у вас во views возникло какое-то действие пользователя, которое должно отправить сообщение в чат-бот. Что делать будете? Приложите код или псевдокод. То, что запуск бота можно положить в команду django для запуска через manage.py -- не решает никаких архитектурных проблем само по себе.

Возвращать ответ как и в обычном Telegram боте. ¯\_(ツ)_/¯
Никаких архитектурных проблем и не было. Просто вам не нужно будет лишний раз заморачиваться с вынесением функционала при написании простого приложения, как и говорилось в статье.

Второй вопрос вынесу отдельно, раз уж ваш chatgpt его тоже проигнорировал.
Что именно вы выигрываете, положив чат-бота именно в команду django?
Чем хуже использовать django.setup() ? Вы ведь про него в курсе, я надеюсь?

Пока что ваш пост напоминает мне "а знаете ли вы, что вы можете сложить любой фоновый процесс в команду django и потом запустить его через django manage.py mycommand ?".

Интересный вы человек однако. В статье так и сказано, что статья не должна перевернуть вас с ног наголову или решить какую-то проблему, а просто напомнить лишний раз что так тоже можно иногда делать.

Ну, по мне, хорошая статья должна не только рассказывать, как можно делать, но и рассказывать, когда так делать следует, а когда -- не следует.

Круто! Мне нравится использовать django для телеграм ботов, как-то делал шаблон для связки django с pytelegrambotapi. Его можно найти на github: blablatidnov/django-telegram-bot-template

Да, мне тоже нравится, ведь данный подход удобен своей простотой и скоростью разработки. Однако, как и говорилось в статье, иногда можно выносить самого бота в отдельный проект, доступный лишь локально на сервере, в целях безопасности, чтобы не перегружать кодовую базу.

Эм, https://github.com/blablatidnov/django-telegram-bot-template выдаёт мне 404.
Вот правильная ссылка: https://github.com/blablatdinov/django-telegram-bot-template
Так, вы используете синхронный АПИ для бота, у вас библиотека телебот -- наоборот, работает только на отправку.
Вы сохраняете все сообщения от бота и к боту в БД, как я и писал выше (но по другой причине).
А для получения входящих сообщений вы подключаетесь через веб-хук.
А как вы читаете пропущенные сообщения за то время, пока бот был выключен? Как вы избегаете двойного подключения к веб-хуку в разных потоках? И как вы к веб-хуку подключаетесь из приватной сети?

Это выглядит как "мы впихнём тебе монитор в монитор, что бы ты смотрел в монитор пока смотришь в монитор".

Куда интереснее было бы почитать про передачу данных из Django в отдельно работающего, скажем на aiogram, бота.

P.S. Насколько я знаю, тг не любит, когда токен бота используется в двух местах одновременно, тогда получается, что эти действия бессмысленны, если есть рабочий бот и надо что-то отправлять из Django?

Да, API Токены это опасная информация которая определенно не должна фигурировать лишний раз. Однако, если выносить Telegram бота в отдельный проект, на языке Python можно реализовать хранение через какую-нибудь ORM вроде SQLAlchemy, а получать информацию через HTTP запросы в формате JSON который будет обрабатывать написанная вами API на более простом фреймворке вроде Flask или FastAPI. В таком случае хранение токена в нескольких проектах не будет необходимостью.

Автор путает пакеты с модулями.

Да, в действительности. Что-то я их перепутал когда писал статью. Объединенные модули называются пакетами.

Ну и? А как собрались запускать сервис джанго и бота одновременно? Или ваш вариант только для или/или?

Сервис Django обычно работает через настроенный WSGI на Gunicorn. А бот можно запускать вручную через консоль сервера или я вам советую более продвинутый метод, это написать админку для вашего бота и управлять его состоянием через подпроцессы реализованные через стандартную библиотеку subprocess

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории