Небольшая задачка по #aws #serverless #telegram_bot

Есть тг бот, работает на AWS Lambda. Приветствует входящих пользователей. Вопрос - как сделать так, чтобы бот через час удалял за собой это сообщение? Условие : serverless решение. В рамках AWS.

Цель : нет нагрузки -> нет трат. Собственно, в этом же и есть преимущество serverless идеологии.

Первое, конечно же что приходит на ум - деплойнуть банальный воркер на минимальный EC2, который будет имитировать простейший scheduler. Может быть cron, может быть простой скрипт зацикленный, который будет ожидать "задания" в виде {messageId}, который нужно удалить в {dateTime}. Но... не хотелось без постоянно поднятой машинки.

Дальше приходит на ум амазоновская очередь SQS. Закидываем в очередь сообщение, ставим ей какой-то readyToHandle в 60 минут. Он через час становится видимым и подписываем на очередь еще одну лямбду, которая автоматически триггернется как только сообщение станет видимо в очереди.
Подходит, но есть одно но - SQS и правда имеет параметр сообщения "DelaySeconds", однако, его максимальное значение - 15 минут. Не подходит.

Вот в целом-то и все доступные варианты, если глянуть поверхностно. Но к счастью, есть ещё один...

Решение

Оказалось, на aws есть сервис States - AWS Step Functions. Машина состояний. Что это такое?

Step Functions — это сервис бессерверной оркестровки, который позволяет комбинировать функции AWS Lambda и другие сервисы AWS для создания критически важных для бизнеса приложений. С помощью графической консоли Step Functions вы видите рабочий процесс своего приложения как серию управляемых событиями шагов. Step Functions основана на конечных автоматах и задачах. Конечный автомат — это рабочий процесс. Задача — это состояние в рабочем процессе, которое представляет собой единицу работы, которую выполняет другой сервис AWS. Каждый шаг рабочего процесса — это состояние (с) habr

Если проще - вы можете "накидать" так называемых шагов на амазоновский юайчик, связать их стрелочками-условиями и быть уверенным, что они исполнятся при определенных условиях. Получается блок-схема. У кого есть айтишное образование точно рисовали такие на парах.

Одним из "степов" может выступать кубик с названием "Wait", который отвечает за "паузу в n ms". Выглядит это вот так. И этот wait time можно в том числе указывать и прграммно. Т.е. данные могут переходить по этим состояниям.

Собственно...подходит! Флоу получился такой :

1. Входит новый пользователь. Лямбда ловит вебхук от телеграма, приветствует пользователя.
2. Лямбда триггерит созданную стейт-машину, передаёт туда условный {messageId} сообщения, которое нужно удалить и время, через сколько секунд.
3. Запускается стейт-машина/флоу на aws. Она переходит в режим ожидания. А через час вызывает мою лямбду, передавая ей мой джсончик с данными.
4. Отдельная лямбда, выполняющая только одну функцию - удаление из тг чата... удаляет сообщение.

PROFIT!

Стоит это всё копейки, при минимальной нагрузке. Что-то а-ля 1000 переходов состояний за 0.025$ + копеечка за лямбду.

Может кому когда понадобится 😉
Если вдруг у вас есть другие workarounds - пишите в комментариях, интересно будет почитать

Кубиты, Квантовые компьютеры - как это работает? Шифрование RSA под угрозой? Или же пока ещё нет?

Все вы слышали про кота Шрёдингера и про какую-то там коробку, в которой одновременно кот существует и не существует, верно? Но ставлю доллар, что навряд ли вы вникали в эту тему. Я не исключение. Ибо не сказать, что я силён в математике и физике чтобы хоть немного понимать сабж.

Но вот вам интереснейшее чтиво на #habr'е, которое пытается "на пальцах" объяснить что есть квантовые компьютеры в сегодняшнем мире, что такое кубит, суперпозиция и квантовая запутанность. А так же каким образом оно может быть полезно для алгоритмики.

Так что если интересно немного расширить кругозор - прыгайте в статью.

ВНИМАНИЕ! Автор хоть и на пальцах написал статью - обязательно дополнительно прочтите все комментарии к ней, ибо, в некоторых утверждениях он (автор) всё же сам не до конца разобрался в некоторых аспектах в теме и в комментариях пришли люди, которые действительно шарят и так же "по полочкам" пояснили. В целом, у вас сложится какое-то начальное понимание, всё довольно доступно изложено.

С этими премиумными статусами телега себе портал в ад открыла! Эпилептики негодуют.

Отключат 💯 , скриньте.

Интересный подкаст вышел у АйтиБороды. С Пашей Либером - создателем белорусской платформы Голос. О цифровом государстве, диктаторах и волонтёрстве. Подкаст/интервью не техническое, но тем не менее весьма интересное. Рекомендасьон

https://www.youtube.com/watch?v=_G5A5-VRYuE

А это mp3 версия, если кому-то так удобнее будет слушать 🤌

Установил убунту под Windows 11 и сравнил производительность. WSL2 vs Native install.

В двух словах - WSL2 позволяет разработчикам получить доступ к Linux среде без виртуалок и double boot'ов. Звучит круто, а чё там по перфомансу-то. В целом - неплохо! Но...

Давайте к замерам. Я взял рабочий ui'ный жирненький проект (nodejs, yarn), прогрел все кеши и сравнил время запуска (по 10 раз и взял быстрейшее время) :

1) И так. Вариант первый - запуск проекта под windows "как есть"
Результат : 39 секунд

2) А теперь ставим убунту под WSL2 (делается кстати в пару кликов) и запуск теперь составляет ...
Результат : 70! секунд

3) А теперь установим чистенькую убунту отдельно и произведем запуск на ней, как думаете, что покажет?
Результат : 22 секунды

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

Что хотелось бы еще добавить : Совсем недавно мелкомягкие завезли в WSL2 демона systemctl, а это значит можно установить красивенький GNOME юайчик и жить как человек! (это мой первый опыт использования убунты на постоянке - через пару месяцев поделюсь фидбеком).

Что еще ... А, да. Если вдруг задумаетесь пользоваться WSL2 - не нужно шарить файлы между разными подсистемами - работает не медленно, а УЛЬТРА МЕДЛЕННО, т.е. если вам нужно запустить проект под юниксом, а он лежит на ntfs - можно повеситься. Запустится, конечно, но примерно к вашей старости. Но фича удобная, конечно, чё уж.

Вот как-то так. Кому было полезно - ставьте 🤡, а кому нет - ставьте 🤌.

Сухих вёсёл вам. отдыхайте 🚣🏽

Разница протоколов