VSCode убогий. Пока он пустой - он очень быстрый, но получается немного лучше блокнота. Как только ему напихаешь батареек как в IDEA, он начинает глючить до невозможного (даже на очень мощных машинах)
Я немного пользователь этой системы... И для меня там выведен целый портал, с помощью которого я могу получать необходимую информацию о курируемых сервисах, а также могу "нажимать удобные кнопки" без риска что-то сломать в продуктивной среде. А какие-то кнопки для меня скрыты, потому что я не сопровожденец :)
Учитывая, что я бывалый пользователь GKE, текущее решение назвать как-то кроме "платформа" - язык не поворачивается
Это не так. Распределение запросов в адрес Telegram Bot API происходит через шардирование (определённые боты ходят на определённые серверы). При необходимости вы можете самостоятельно развернуть такой сервер у себя.
Начинаешь читать - вроде по делу написано. Но когда смотришь на код, переживаешь за тех, кто по нему будет учиться.
Сессии и соединения создаются при каждом запросе - плохо. Таски создаются через класс, вместо фабрики - не рекомендуется. Вместо цикла в воркерах рекурсивно копится стек вызовов - плохо. Вместо передачи аргументов запросы формируются небезопасным образом - очень плохо. И это далеко не всё...
Автору рекомендую подкрепить задор прохождением курсов или наймом ментора.
Ищите проблему в своей реализации. У меня несколько миллионов активных пользователей, генерящих тысячи rps. Поллинг столько физически не тянет, а вебхуки позволяют скейлить сервис и оперативно разгребать всё, что к нему прилетает
Одна из немногих причин использования вебхуков вместо поллинга – возможность скейлить приложение. Подход с установкой и удалением вебхуков, показанный в примере с lifespan, превратит скейлинг в ад.
При старте приложения можно получить информацию об установленном вебхуке. Если настройки соответствуют, то можно смело ничего не делать. А если не соответствуют - вот тогда уже выполнять настройку. Удалять вебхук при завершении приложения крайне не рекомендую: замена контейнера сварме/кубере приведёт к гарантированному удалению вебхука при работающем приложении.
Да, Clickhouse не очень хорош при обработке большого кол-ва запросов, НО у него из коробки есть возможность самостоятельно читать очереди в брокерах сообщений. Т.е. можно лить весь трафик в условный rabbit / kafka с удобной вам скоростью, а дальше Clickhouse будет самостоятельно стягивать необходимую информацию с комфортной ему скоростью
Есть ощущение, что это будет эффективнее, чем размазывать запросы через round robin
Пользователь неактивен - пусть воркер спит. Когда SSE на стороне клиента перестанет вычитывать `: ping` от сервера, сервер может спокойно разорвать соединение.
Когда пользователь станет активным и Service Worker проснётся, он увидит разорванный стейт и пойдёт переподключаться. Если вы передаёте id в отправляемых сообщениях, то при переподключении SSE передаст идентификатор последнего полученного в заголовке "Last-Event-Id" - дальше у бэка есть всё для принятия решения (отдавать пропущенные или нет).
Замечания по делу были. Зря у вас включается защитная реакция.
Синтаксис python идёт вперёд, как бы вы не привыкли к старому. На мой взгляд, это не всегда удобно, но факт остаётся фактом.
Если уж вы делаете файл с тестами, то pytest в его простом варианте усложнения статье не добавит. Всего-то функцию переименовать и assert добавить.
В идеале, прогоните свой код через ruff с проверкой ALL + форматтером. Это поможет немного защититься как от плохих, так и от устаревших практик.
В остальном статья действительно будет полезна для новичков. Язык повествования весьма простой и понятный.
Спасибо
VSCode убогий. Пока он пустой - он очень быстрый, но получается немного лучше блокнота. Как только ему напихаешь батареек как в IDEA, он начинает глючить до невозможного (даже на очень мощных машинах)
Проблема шире, там не только Java.
Я в их редакторах использую Python, Rust, JS, Golang
Но в целом - пох: загрузил через VPN, продолжаю пользоваться.
Не на VSCode же уходить)))
Я немного пользователь этой системы... И для меня там выведен целый портал, с помощью которого я могу получать необходимую информацию о курируемых сервисах, а также могу "нажимать удобные кнопки" без риска что-то сломать в продуктивной среде. А какие-то кнопки для меня скрыты, потому что я не сопровожденец :)
Учитывая, что я бывалый пользователь GKE, текущее решение назвать как-то кроме "платформа" - язык не поворачивается
Держите пошаговую инструкцию для проверки:
https://core.telegram.org/reproducible-builds
Держите пошаговую инструкцию для проверки:
https://core.telegram.org/reproducible-builds
Документация: https://core.telegram.org/bots/api#using-a-local-bot-api-server
Пример: https://github.com/Olegt0rr/telegram-local
Это не так. Распределение запросов в адрес Telegram Bot API происходит через шардирование (определённые боты ходят на определённые серверы). При необходимости вы можете самостоятельно развернуть такой сервер у себя.
Начинаешь читать - вроде по делу написано. Но когда смотришь на код, переживаешь за тех, кто по нему будет учиться.
Сессии и соединения создаются при каждом запросе - плохо. Таски создаются через класс, вместо фабрики - не рекомендуется. Вместо цикла в воркерах рекурсивно копится стек вызовов - плохо. Вместо передачи аргументов запросы формируются небезопасным образом - очень плохо. И это далеко не всё...
Автору рекомендую подкрепить задор прохождением курсов или наймом ментора.
Ищите проблему в своей реализации. У меня несколько миллионов активных пользователей, генерящих тысячи rps. Поллинг столько физически не тянет, а вебхуки позволяют скейлить сервис и оперативно разгребать всё, что к нему прилетает
Одна из немногих причин использования вебхуков вместо поллинга – возможность скейлить приложение. Подход с установкой и удалением вебхуков, показанный в примере с lifespan, превратит скейлинг в ад.
При старте приложения можно получить информацию об установленном вебхуке. Если настройки соответствуют, то можно смело ничего не делать. А если не соответствуют - вот тогда уже выполнять настройку. Удалять вебхук при завершении приложения крайне не рекомендую: замена контейнера сварме/кубере приведёт к гарантированному удалению вебхука при работающем приложении.
За сертификаты отвечает реверс-прокси, не надо пичкать этим ни аиограм, ни фастапи
Упомянутую проблему c
business_opening_hoursне удалось воспроизвести.Поле
business_opening_hoursдаже в ChatFullInfo заявлено какOptional. ЗначениеNone- это нормально.В объекте Chat, присылаемом с Message, поля
business_opening_hoursпопросту нет.Пример использования написал в комментариях к issue:
https://github.com/aiogram/aiogram/issues/1490
Почему для свежей статьи была выбрана такая версия
pydantic-settings?class Configуже заменили наmodel_config
https://docs.pydantic.dev/latest/concepts/pydantic_settings/#usageДля секретов рекомендуется использовать вот такое поле: https://docs.pydantic.dev/dev/api/types/#pydantic.types.SecretStr
Да, учитывая нюансы, это выглядит как +1 ETL сервис в цепочке поставок.
Но в свою очередь он:
Решает проблему скейлинга кликхауса
Сам элементарно скейлится
Позволяет гибко крутить-вертеть данные, буквально в полёте и маршрутизировать поток данных как и куда хотите.
Пишется на любом удобном языке меньше, чем за 1 спринт
Не требует регулярных доработок (сделал и забыл)
Да, Clickhouse не очень хорош при обработке большого кол-ва запросов, НО у него из коробки есть возможность самостоятельно читать очереди в брокерах сообщений. Т.е. можно лить весь трафик в условный rabbit / kafka с удобной вам скоростью, а дальше Clickhouse будет самостоятельно стягивать необходимую информацию с комфортной ему скоростью
Есть ощущение, что это будет эффективнее, чем размазывать запросы через round robin
А что плохого в засыпаниях?
Пользователь неактивен - пусть воркер спит. Когда SSE на стороне клиента перестанет вычитывать `: ping` от сервера, сервер может спокойно разорвать соединение.
Когда пользователь станет активным и Service Worker проснётся, он увидит разорванный стейт и пойдёт переподключаться. Если вы передаёте id в отправляемых сообщениях, то при переподключении SSE передаст идентификатор последнего полученного в заголовке "Last-Event-Id" - дальше у бэка есть всё для принятия решения (отдавать пропущенные или нет).
И в ту же копилку цитат от автора: "[asyncpg] Всего в 2 раза лучше, чем psycopg2"
Я больше 5 лет арендую серверы у другой российской компании
Локация: Амстердам
16 CPU 3.4 GHz
16 GB RAM
50 Gb nve/ssd/hdd
Ваш калькулятор: 9940 ₽ / месяц
Калькулятор другой компании: 6858 ₽ / месяц
Калькулятор hetzner (соседняя локация, но доп. 16 GB RAM сверху): 5 386 ₽ / месяц
Почему я должен переехать к вам? :)
Ещё один готовый набор для кафки:
https://github.com/confluentinc/cp-all-in-one