Комментарии 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 -- не решает никаких архитектурных проблем само по себе.
Второй вопрос вынесу отдельно, раз уж ваш 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
Интеграция Telegram ботов в Django приложениях