Интересный вы человек однако. В статье так и сказано, что статья не должна перевернуть вас с ног наголову или решить какую-то проблему, а просто напомнить лишний раз что так тоже можно иногда делать.
Возвращать ответ как и в обычном Telegram боте. ¯\_(ツ)_/¯ Никаких архитектурных проблем и не было. Просто вам не нужно будет лишний раз заморачиваться с вынесением функционала при написании простого приложения, как и говорилось в статье.
Сервис Django обычно работает через настроенный WSGI на Gunicorn. А бот можно запускать вручную через консоль сервера или я вам советую более продвинутый метод, это написать админку для вашего бота и управлять его состоянием через подпроцессы реализованные через стандартную библиотеку subprocess
Хорошо, давайте попробую ответить на ваши вопросы по порядку)
1. Передавать данные в Telegram: Само содержимое файлов Django приложения никак не обязывает разработчика использовать представления фреймворка в целях обработки сообщений и вызова команд. Напротив, в том же файле представлений можно прописать обработчики сообщений используя классы и функции библиотек которые будут возвращать результат в виде отправки сообщения или редактирования уже существующего (например для меню).
Во вторых, далеко не обязательно сохранять историю сообщений с пользователем ведь часто в этом нет необходимости, да и это противоречит главной политике самих чат ботов. По их изначальной задумке они должны вести частную переписку с пользователем и лишь обрабатывать запросы, а не хранить их. От того большой необходимости в постоянном редактировании базы данных нет.
Разве, что хранение пользователей и информации о них, но чтобы оптимизировать эту операцию можно применить хэш таблицы где формат ключ - значение идеально подойдет под Telegram ID пользователя и его запись в базе данных (для которой кстати Telegram ID можно использовать в роли первичного ключа).
2. Получать данные из Telegram: Здесь отчасти соглашусь, Django не предоставляет полноценной поддержки асинхронного программирования из-за чего приходится прибегать к использованию сторонних библиотек.
С другой стороны Telegram боты не всегда имеют настолько большие нагрузки, от того в статье и было указано, что данный подход удобен лишь при разработке на скорость и относительно небольшой кодовой базе Telegram бота. Если ваша функциональность выходит за рамки предельной производительности данного подхода, то смело пишите отдельный проект и связывайте их любым известным вам способом.
Если у вас возникнут еще вопросы по поводу статьи или данные выше ответы не полностью покрывают ваш интерес, то пишите в комментарии, я обязательно отвечу)
Да, API Токены это опасная информация которая определенно не должна фигурировать лишний раз. Однако, если выносить Telegram бота в отдельный проект, на языке Python можно реализовать хранение через какую-нибудь ORM вроде SQLAlchemy, а получать информацию через HTTP запросы в формате JSON который будет обрабатывать написанная вами API на более простом фреймворке вроде Flask или FastAPI. В таком случае хранение токена в нескольких проектах не будет необходимостью.
Да, мне тоже нравится, ведь данный подход удобен своей простотой и скоростью разработки. Однако, как и говорилось в статье, иногда можно выносить самого бота в отдельный проект, доступный лишь локально на сервере, в целях безопасности, чтобы не перегружать кодовую базу.
С базой данных можно взаимодействовать через импортирование моделей Django. Там же можно создать модель Telegram пользователя и хранить их информацию. В одном из первых стартапов, я как-то писал декоратор который по ID Telegram пользователя в сообщении авторизовывал его связывая Telegram ID с его учетной записью в общей базе данных.
Интересный вы человек однако. В статье так и сказано, что статья не должна перевернуть вас с ног наголову или решить какую-то проблему, а просто напомнить лишний раз что так тоже можно иногда делать.
Возвращать ответ как и в обычном Telegram боте. ¯\_(ツ)_/¯
Никаких архитектурных проблем и не было. Просто вам не нужно будет лишний раз заморачиваться с вынесением функционала при написании простого приложения, как и говорилось в статье.
Сервис Django обычно работает через настроенный WSGI на Gunicorn. А бот можно запускать вручную через консоль сервера или я вам советую более продвинутый метод, это написать админку для вашего бота и управлять его состоянием через подпроцессы реализованные через стандартную библиотеку
subprocessДа, в действительности. Что-то я их перепутал когда писал статью. Объединенные модули называются пакетами.
Хорошо, давайте попробую ответить на ваши вопросы по порядку)
1. Передавать данные в Telegram:
Само содержимое файлов Django приложения никак не обязывает разработчика использовать представления фреймворка в целях обработки сообщений и вызова команд. Напротив, в том же файле представлений можно прописать обработчики сообщений используя классы и функции библиотек которые будут возвращать результат в виде отправки сообщения или редактирования уже существующего (например для меню).
Во вторых, далеко не обязательно сохранять историю сообщений с пользователем ведь часто в этом нет необходимости, да и это противоречит главной политике самих чат ботов. По их изначальной задумке они должны вести частную переписку с пользователем и лишь обрабатывать запросы, а не хранить их. От того большой необходимости в постоянном редактировании базы данных нет.
Разве, что хранение пользователей и информации о них, но чтобы оптимизировать эту операцию можно применить хэш таблицы где формат ключ - значение идеально подойдет под Telegram ID пользователя и его запись в базе данных (для которой кстати Telegram ID можно использовать в роли первичного ключа).
2. Получать данные из Telegram:
Здесь отчасти соглашусь, Django не предоставляет полноценной поддержки асинхронного программирования из-за чего приходится прибегать к использованию сторонних библиотек.
С другой стороны Telegram боты не всегда имеют настолько большие нагрузки, от того в статье и было указано, что данный подход удобен лишь при разработке на скорость и относительно небольшой кодовой базе Telegram бота. Если ваша функциональность выходит за рамки предельной производительности данного подхода, то смело пишите отдельный проект и связывайте их любым известным вам способом.
Если у вас возникнут еще вопросы по поводу статьи или данные выше ответы не полностью покрывают ваш интерес, то пишите в комментарии, я обязательно отвечу)
Да, API Токены это опасная информация которая определенно не должна фигурировать лишний раз. Однако, если выносить Telegram бота в отдельный проект, на языке Python можно реализовать хранение через какую-нибудь ORM вроде SQLAlchemy, а получать информацию через HTTP запросы в формате JSON который будет обрабатывать написанная вами API на более простом фреймворке вроде Flask или FastAPI. В таком случае хранение токена в нескольких проектах не будет необходимостью.
Да, мне тоже нравится, ведь данный подход удобен своей простотой и скоростью разработки. Однако, как и говорилось в статье, иногда можно выносить самого бота в отдельный проект, доступный лишь локально на сервере, в целях безопасности, чтобы не перегружать кодовую базу.
С базой данных можно взаимодействовать через импортирование моделей Django. Там же можно создать модель Telegram пользователя и хранить их информацию. В одном из первых стартапов, я как-то писал декоратор который по ID Telegram пользователя в сообщении авторизовывал его связывая Telegram ID с его учетной записью в общей базе данных.