Telegram-бот на Python: библиотеки и устройство проекта

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

Библиотеки

• aiogram — асинхронный фреймворк, популярный в русскоязычном сообществе; поддерживает роутеры, фильтры, промежуточные обработчики и машину состояний
• python-telegram-bot — давно развивающаяся библиотека с подробной документацией; в актуальных версиях тоже асинхронная
• pyTelegramBotAPI — простая библиотека для небольших ботов

Асинхронность важна, когда бот обслуживает много пользователей одновременно и обращается к внешним сервисам: пока один запрос ждёт ответа от CRM, бот продолжает отвечать другим.

Обработчики и роутеры

Бот реагирует на события: команды, текст, нажатия кнопок, фото, документы, платежи. Для каждого события пишется обработчик. В нормальном проекте обработчики разделены по модулям: каталог, корзина, профиль, администрирование. Роутеры собирают их в одно приложение. Если все обработчики лежат в одном файле на тысячу строк, поддерживать бота становится тяжело. Промежуточные обработчики — middleware — удобны для общих задач: определить язык пользователя, проверить, не заблокирован ли он, записать действие в журнал, открыть соединение с базой.

Клавиатуры

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

Состояния диалога

Многошаговые сценарии — оформление заказа, запись, анкета — требуют помнить, на каком шаге находится пользователь и что он уже ввёл. Для этого используют машину состояний. В разработке состояния можно хранить в памяти, но в рабочем боте — в Redis или базе данных, иначе при перезапуске все незавершённые диалоги потеряются.

База данных

Пользователи, заказы, настройки, история обращений хранятся в базе: SQLite подходит для прототипа, PostgreSQL — для рабочего проекта. Доступ к базе организуют через ORM или отдельный слой работы с данными, а изменения структуры — через миграции, чтобы обновление бота не ломало данные.

Конфигурация и секреты

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

Типичная структура проекта

• точка входа, где создаётся бот и подключаются роутеры
• модули обработчиков по разделам
• клавиатуры и тексты отдельно от логики, что упрощает перевод на узбекский
• слой работы с базой данных
• клиенты внешних сервисов: CRM, платежи, учёт
• конфигурация, миграции, тесты

Развёртывание

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

Что проверить заказчику

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