Смысл не в SQLite, а в SQLAlchemy. Достаточно ссылку заменить на подключение и все прекрасно будет работать с PostgreSQL. Тот же код. Возможно некорректно выразился)
FastApi в этом проекте закрыл вопрос подъема бота (вебхуки) и отрисовал страницы для MiniApp. Если я уже прикрутил его, почему тогда не использовать его по прямому назначению? По вашей анологии в гараже стоит и велосипед и мотоцикл. Зачем ехать на велосипеде?
А как вы работаете с базами данных в своих FastApi приложениях без Alembic?
Здесь имеется в виду обрывание импортов ради вызова sys, да, с Alembic я не знаком, но не нудаю что прям жизненно необходимо написать 2 импорта, потом вызов sys(в котором я не вижу ничего плохо, для меня странно только его расположение в коде), а потом только остальные импорты.
Я считаю, что вам нужно разобраться в вопросе, а после делать замечания к таким кускам кода.
В данном случае мы «обманули» Alembic, заставив его думать, что он находится в папке app. Это необходимо, чтобы Alembic правильно обрабатывал импорты и понимал, как они работают в контексте проекта.
Благодаря такому подходу появилась возможность выполнять импорт класса Base и модели. То есть, это, действительно "жизненно важно", так как по другому Alembic работать не будет.
А зачем тогда использовать FastAPI, если есть socket?)
Судя по этой шутке вы и с FastApi не особо знакомы, да?
1)Не используйте(пожалуйста) call.message.anwser при ответе на inline. Есть edit_text/подобная функция. Telegram ждёт ответа на кнопку(это хоть здесь и реализовано, но накидывает много лишних сообщений, которые можно перекрыть одним edit_text)
Бывают разные ситуации. Я писал больше 12-ти крупных статей по аиграм и очень хорошо осведомлен о всех методах. В текущем коде мне показался такой подход более уместный.
2)Странная логика написания кода. Где-то импорта логически разделены(через Enter), где то посредине импорта стоит sys) Где-то один отступ перед функцией, а где-то два. Странная логика
Это не логика написания кода, а логика его сюда вставки. Когда статья перекатывает за 20 минут чтения начинаются очень серьезные глюки в оформлении. Кроме того, это никакого отношения к логике не имеет.
"посредине импорта стоит sys". Расскажите, пожалуйста, а как в текущей логике кода получить тот же результат миграций Alembic без использования "посередине импорта sys". Вы знакомы с этой технологией? Приложение запускается с корня проекта. Нужно к нему прикрутить модели алхимии и прочее. Просто интересно, просвятите)
3)Закрывать через
Это классический синтаксис и как по мне он более понятный.
4)Очень опционально, но улучшает пользовательский опыт - постановка цветов темы из телеграмма (в документации в красках все расписано). То же касается MainButton, showAlert и тд
Ограничения. Я всегда стараюсь в подобных проектах отходить от готового кода JavaScript телеграм. Как по мне он сильно ограничивает.
Сама тема интересная, но не особо раскрыта тема telegram mini apps js(там очень много интересных функций есть, но про них почему-то никто не говорит)
Есть FastApi и JavaScript. Зачем использовать чужое если можно написать полностью свое и под себя?)
Я думаю причина многих вопросов в том, что вы не вчитывались в статью, а, точнее, не читали.
Я считаю что это все извращения) Есть подход запуска через бэкенд. Вот, как я в статье показал, например, с FastApi и есть подход с NextJS, в котором с коробки идет скрытие переменных окружения. Все остальное не имеет никакого смысла. В статье просто хотел показать, как просто интегрировать формы с сайта и телеграмм ботов. Не больше и не меньше)
А у вас есть идеи о том как выполнить связку формы на сайте с телеграмм ботом на чистом JS без открытого токена? Старался соостветствовать названию статьи)
В этой статье не было цели перегружать читателя лишней информацией. Основная задача — показать, насколько просто интегрировать Telegram-ботов в формы на сайте, а не углубляться в детали обеспечения максимальной безопасности формы.
Согласен, хорошее замечание! Действительно, текущая реализация чата работает только при единственном инстансе бэкэнда, и при масштабировании проекта важно учитывать синхронизацию данных между инстансами. В будущем планирую рассмотреть подходы с использованием Pub/Sub (например, Redis или Kafka), чтобы реализовать корректную передачу сообщений и событий между различными инстансами. Спасибо за рекомендацию!
Спасибо за замечание. Учту. А str, Enum и int, Enum не будет так-же работать?
Смысл не в SQLite, а в SQLAlchemy. Достаточно ссылку заменить на подключение и все прекрасно будет работать с PostgreSQL. Тот же код. Возможно некорректно выразился)
FastApi в этом проекте закрыл вопрос подъема бота (вебхуки) и отрисовал страницы для MiniApp. Если я уже прикрутил его, почему тогда не использовать его по прямому назначению? По вашей анологии в гараже стоит и велосипед и мотоцикл. Зачем ехать на велосипеде?
А как вы работаете с базами данных в своих FastApi приложениях без Alembic?
Я считаю, что вам нужно разобраться в вопросе, а после делать замечания к таким кускам кода.
В данном случае мы «обманули» Alembic, заставив его думать, что он находится в папке
app. Это необходимо, чтобы Alembic правильно обрабатывал импорты и понимал, как они работают в контексте проекта.Благодаря такому подходу появилась возможность выполнять импорт класса Base и модели. То есть, это, действительно "жизненно важно", так как по другому Alembic работать не будет.
Судя по этой шутке вы и с FastApi не особо знакомы, да?
Бывают разные ситуации. Я писал больше 12-ти крупных статей по аиграм и очень хорошо осведомлен о всех методах. В текущем коде мне показался такой подход более уместный.
Это не логика написания кода, а логика его сюда вставки. Когда статья перекатывает за 20 минут чтения начинаются очень серьезные глюки в оформлении. Кроме того, это никакого отношения к логике не имеет.
"посредине импорта стоит sys". Расскажите, пожалуйста, а как в текущей логике кода получить тот же результат миграций Alembic без использования "посередине импорта sys". Вы знакомы с этой технологией? Приложение запускается с корня проекта. Нужно к нему прикрутить модели алхимии и прочее. Просто интересно, просвятите)
Это классический синтаксис и как по мне он более понятный.
Ограничения. Я всегда стараюсь в подобных проектах отходить от готового кода JavaScript телеграм. Как по мне он сильно ограничивает.
Есть FastApi и JavaScript. Зачем использовать чужое если можно написать полностью свое и под себя?)
Я думаю причина многих вопросов в том, что вы не вчитывались в статью, а, точнее, не читали.
А решение с FastApi это не быстрое и простое решение для этих задач?
Да. Тут нужно перенести Try. Except блок на уровень отправки сообщения. Спасибо, что обратили внимание)
Я считаю что это все извращения) Есть подход запуска через бэкенд. Вот, как я в статье показал, например, с FastApi и есть подход с NextJS, в котором с коробки идет скрытие переменных окружения. Все остальное не имеет никакого смысла. В статье просто хотел показать, как просто интегрировать формы с сайта и телеграмм ботов. Не больше и не меньше)
Так это уже не чистый JS) Там бэкенд, Python)
Спасибо за обратную связь)
А у вас есть идеи о том как выполнить связку формы на сайте с телеграмм ботом на чистом JS без открытого токена? Старался соостветствовать названию статьи)
Все равно я считаю что в контексте этой статьи капча и прочее - это перегруз лишней информацией. ИМХО
В этой статье не было цели перегружать читателя лишней информацией. Основная задача — показать, насколько просто интегрировать Telegram-ботов в формы на сайте, а не углубляться в детали обеспечения максимальной безопасности формы.
https://habr.com/ru/articles/829742/
В этой статье описывал подробно
Спасибо за обратную связь)
Согласен, хорошее замечание! Действительно, текущая реализация чата работает только при единственном инстансе бэкэнда, и при масштабировании проекта важно учитывать синхронизацию данных между инстансами. В будущем планирую рассмотреть подходы с использованием Pub/Sub (например, Redis или Kafka), чтобы реализовать корректную передачу сообщений и событий между различными инстансами. Спасибо за рекомендацию!
TelegramBotApi ставит это ограничение только на физическую загрузку / отправку файлов.
Спасибо за обратную связь. Решил более явно указать в коде, но согласен. В боевых проектах лучше использовать такой синтаксис.
upd: Добавил ваш пример кода в статью. Ещё раз спасибо)
Нужно подумать. Мысль интересная)
Спасибо за поддержку)