Как подключать БД к ботам телеграм
Вопрос не про код, а про архитектуру и best practice, которая обеспечит безопасность и гибкость обслуживания.
Для примера возьмем PostgreSQL, python. Нет большой разницы здесь.
Первое, это решение в лоб, то есть писать подключение на прямую к базе данных через psycopg2 и в боте вызывать те или иные конструкции для данных (забрать, обновить, удалить и создать).
Второе, это решение через API. Почему бы не создать базу данных, опираясь на sqlalchemy или django (может быть громоздко, но удобно создавать модели) и открыть для бота доступ по API, в стандарте RESTful через FastAPI или DRF.
Какое решение применить для ТГ бота со средней нагрузкой? Кто пишет боты, дайте ответ
PS python и его модули только для примера, если есть результаты для другого стэка пишите
Ответы (3 шт):
На вход — любой асинхронный фреймворк, их сейчас много. На базу - TortoiseORM, она быстрая, асинхронная и вдохновлена Django ORM (кто знает её, тот быстро освоится). Драйвер БД соответственно тоже будет асинхронным (например, asyncpg). Ну и промежуточные данные, которые нет смысла хранить постоянно, лучше складывать в какой-нибудь Redis.
Для бота со средней нагрузкой (скажем, несколько сотен запросов в минуту) я бы рекомендовал использовать подход через API.
FastAPI лучше DRF, так как он асинхронный и быстрее, а в боте логика обычно завязана на asyncio. API можно держать отдельно и масштабировать.
моделирование данных: Используя ORM (SQLAlchemy или Django ORM), можно упростить работу с моделями и обеспечить единообразие бизнес-логики.
Если я правильно понял, есть две идеи. Взаимодействовать ли с базой данных напрямую, через драйвера (asyncpg, psycopg2 и др.) или развернуть отдельное REST API, к которому будет обращаться бот?
Как мне кажется, ответить на вопрос можно, разобравшись в нескольких аспектах:
- Есть ли сейчас время на создание API (на самом деле, спроектировать REST API достаточно трудно, если все не требования к API определены, и в условиях нехватки времени сложно будет учесть всё с первого раза)?
- Будет ли время на поддержку такого API (если вы пишете проект в одиночку, вы не планируете масштабировать Telegram бота, добавлять какие-то внешние сервисы и пр., то, возможно, надобности в API нет)?
То есть всё вышеперечисленное сводится к тому, есть ли в этом необходимость? Насколько это нужно вашему проекту? Если вы правда планируете использовать API не только для бота, но и для админки, других сервисов, то, может быть, в этом и есть смысл. Но точного ответа никто, кроме архитектора в проекте, дать не сможет, потому что детали слишком размыты.
Приведу пример, почему я так считаю. Например, если вы у вас Telegram бот задействует серьёзный математический аппарат (то есть у вас приложение нагружено именно вычислениями, а не данными), то скорее всего стек нужно будет основательно пересматривать.
Также вам никто не запрещает развернуть API в том же приложении, где и используется Telegram бот, aiogram это позволяет.
Насчёт стека я бы отметил следующую вариацию:
- aiohttp (потому что на нём и работает aiogram), aiogram, sqlalchemy (в связке с asyncpg)
В такой связке вы сможете развернуть API и использовать модели, которые вам даст sqlalchemy.
На вопрос производительности ответить невозможно, потому что существует слишком много факторов, из-за которых предсказать, какая у вас будет производительность и что нужно будет оптимизировать, невозможно. Все решения в данном случае будут уникальны, со своей спецификой. Сейчас стало модно использовать повсеместно асинхронность. Приведённый выше стек асинхронен, но здесь нужно ещё учитывать, что будет происходить в проекте, потому что поддерживать асинхронные приложения достаточно трудно, ввиду сложной темы для в проекте, которые не используют asyncio.