Web-технологии

Где-то 2 года назад, команда Telegram выкатили Telegram Stars. "Звездочки", которыми можно оплачивать цифровые товары. На момент написания этой статьи, за окном конец 2025 и меня посещает мысль: окей, у меня есть парочка ботов на n8n, в целом, я не против, чтобы они приносили деньги. Где тут кнопка "Принять бабло?"

Спойлер: её нет.

Команда n8n делает хороший продукт, но они не всегда успевают за скоростью релизов телеграма (это моя гипотеза, как на самом деле – не знаю). Штатная нода умеет отправлять сообщения, кнопки, картинки, но как только дело доходит до sendInvoice или обработки preCheckoutQuery… всё, приехали. Либо пиши HTTP Request с кучей параметров и изучай документацию API, либо… страдай. Ну и ещё приходится в таком кейсе палить свой токен бота.

Был ещё один путь. Решил закрыть гештальт, сделать свой первый Open Source вклад и заодно протестировать подход Vibe кодинг.

Vibe Coding? Чего?

Кратко про вайб-кодинг: это когда ты не пишешь код символ за символом, а "вайбишь" с ИИ-ассистентом (в моем случае – Cursor), объясняя ему, что ты хочешь получить на выходе. Ты архитектор, AI строитель.

Я не хотел тратить неделю на изучение архитектуры и возможности нод n8n, разбираться в их UI-компонентах, правилах и типах данных. Я хотел результат: ноду, которую можно перетащить в редактор и начать чарджить юзеров.

Пройдусь буквально по верхам, что именно мне помогло:

• MCP Content7 (документация по n8n) + дока по стилю UI от авторов n8n

• Пример реализации custom ноды от другого автора

Возможно, дочитав до этого момента, вы можете задаться вопросом. "Постой, ты хочешь сказать, что навайбкодил то, что связанно с деньгами/платежами. Автор вообще в своём уме? Какой нафиг доверие всему этому?!"

И… отчасти вы правы. Я хоть и большую часть своей карьеры был (и чуть-чуть продолжаю им быть) как QA, знаю там про тестирование и качество, но никогда и нигде не утверждал и не буду утверждать, что тут всё работает как часы. Я тестировал получившийся код, и этот же код использую в своих проектах. Также в каждой ноде есть дисклеймер о том, что могут быть ошибки и что используйте на свой страх и риск.

В любом случае, я предоставлю вам "базу", всё под лицензией MIT, поэтому если уж хотите энтерпрайз – всё в ваших руках.

Что получилось: n8n-nodes-telegram-stars

Я собрал кастомную ноду, которая оборачивает основные методы Payments API Телеграма по работе с звёздами.

🔗 GitHub: Vlad-Loop/n8n-nodes-telegram-stars

📦 NPM: n8n-nodes-telegram-stars

Она не идеальна, местами может быть сыровата (это v1 всё таки), но она закрывает главную боль – монетизация ботов без кода (почти).

Что умеет эта штука?

• Send Invoice: Генерирует счет на оплату. Указываем цену, валюту (XTR), описание и юзер получает красивую плашку "Заплати мне за столько звёзд".

• Answer Pre-Checkout Query: Самая важная часть. Перед тем как списать деньги, Телеграм стучится к боту: "Эй, всё норм? Деньги брать?". Если вы не ответите за 10 секунд – платеж отменится. Нода позволяет дать ответ, либо отказ.

• Refund Star Payment: Если вы честный человек (или просто накосячили), деньги можно вернуть одной кнопкой. Рефанды – это база для роста лояльности.

• Get Transactions: Посмотреть историю транзакций и баланс бота. Полезно для админки.

• Get Bot Balance: Ну, тут понятно. Чтобы греть душу цифрами.

Как это работает "под капотом"? (Разбор воркфлоу)

Давайте уйдем от теории к практике. Я собрал тестовый сценарий (вот тут можно найти ссылку на него), который делает полный цикл покупки.В n8n всё крутится вокруг логики. Вот как выглядит типичный флоу оплаты "Звездами":

1. Триггер и Роутинг

У нас есть стандартный Telegram Trigger. Он ловит всё. Дальше стоит Switch (или Router), который смотрит, что прилетело. В моем примере я разделил логику на:

/donate – хочу купить.

/refund – верните деньги (тест механики).

/bot_balance – чекнуть баланс.

И самое важное: системные события оплаты.

2. Выставление счета (Invoice)

Юзер пишет /donate. Мы дергаем мою кастомную ноду с методом sendInvoice.Price Amount: 10 звезд.

Payload: Уникальный ID заказа (я туда зашил message_id, но по-хорошему там должен быть ваш internal order ID). Юзер видит кнопку "Pay 10 Stars". Нажимает.

3. Pre-Checkout

Как только юзер нажал "Оплатить", Телеграм шлет апдейт типа pre_checkout_query. Здесь многие спотыкаются на HTTP-запросах. В моем воркфлоу стоит фильтр: если пришел pre_checkout_query — отправляем его в ноду с методом answerPreCheckoutQuery. Всё. Телеграм получил "ОК" и списал звезды у юзера.

Небольшой поучительный кейс. Когда это может быть полезно: например юзер около 5-ти месяцев назад, в вашем боте решил купить какую-либо услугу, у вас тогда это стоило 10 звёзд. Время идёт, инфляция съедает даже звёзды, цены растут. Теперь ваша услуга стоит 20 звёзд. Но у пользователя есть сообщение, кнопка, где цена 10. Он нажимает и если у вас нет никакого фильтра на этапе Pre-Checkout – он заплатит 10 звезд и получит услугу. Я например поставил у себя в ботах сверку даты, что если с момента создания сообщения с кнопкой оплаты и фактического получения события о проверке оплаты прошло больше 10 минут – не принимаю оплату и отправляю новое сообщение с кнопкой оплаты, где потенциально может быть новая цена.

4. Успешная оплата и… Возврат?

После списания прилетает successful_payment. Тут мы радуемся, записываем charge_id в базу (или в Google Sheets, максимально не советую, но знаю, что в комьюнити n8n есть и такие любители подобного) и выдаем юзеру его цифровой товар.А если нужно вернуть? Я добавил логику: берем charge_id из успешной оплаты, скармливаем ноде с методом refundStarPayment – и деньги возвращаются юзеру. Мгновенно.

Почему не просто HTTP Request?

Можно же через обычный HTTP Request ноду дергать API Телеграма. Можно. Но:

• Вам нужно каждый раз гуглить структуру JSON-пейлоада. Ну либо держать в блокноте или как пример.

• Вам нужно помнить названия эндпоинтов.

• Это выглядит грязно в редакторе.

• Ваш токен в 90% случаев будет торчать "наружу". Поделится с другом или коллегой примером вашего воркфлоу, ну мягко говоря не получится.

Кастомная нода дает вам красивый UI с полями. Вы выбираете "Refund", вставляете ID, и всё работает. Это экономит когнитивное топливо. А мы тут за автоматизацию, чтобы меньше думать о рутине.

Как установить?

Если у вас self-hosted n8n (а мы же тут все серьёзные ребята и топим за local-first, да?), то идем в: Settings → Community Nodes → Install → вбиваем n8n-nodes-telegram-stars.

Если у вас Cloud-версия… ну, напишите в саппорт n8n, чтобы они разрешили кастомные ноды, или поднимайте свой инстанс. Docker-контейнер поднимается за 5 минут, не ленитесь. Вот тут писал гайд, как это сделать.

Про то, как дебажить и создать связь напрямую с инстансом n8n на устройстве – всё есть на страничке гитхаб.

Выводы и философия

Этот кейс для меня не только про "прикрутить платежку". Это про то, как меняется разработка. Раньше создание такой ноды заняло бы у меня несколько выходных с чтением доков по TypeScript и архитектуре n8n. С Cursor я сделал основной функционал за вечер.

А ещё, для меня наступает удивительное время, когда барьер между "Идея" и "Готовый инструмент" стирается. Если вам чего-то не хватает в вашем инструменте автоматизации – не ждите вендора. Возьмите AI, возьмите бойлерплейт и сделайте сами.

Ну и качайте ноду, пробуйте. Если найдете баги (а они там есть, я уверен) – велкам в Issues на гитхабе или пишите пулл-реквесты. Open Source в моём понимании, всё же больше уходит в коллективный разум.

P.S. Какой самый странный процесс вы пытались монетизировать в боте? Расскажите в комментах, оценим или восхитимся.

Ваш сценарий в n8n отлично работал на 10 задачах, но «завис» на 1000? Если процесс выполняется часами, а в логах маячит ошибка Timeout, виноват, скорее всего, стандартный узел Loop Over Items.

Этот узел надёжен, но работает последовательно: берёт один элемент, прогоняет по всей цепочке, ждёт — и только потом берёт следующий. Если каждая итерация из-за медленного API занимает 5–10 секунд, обработка 1000 элементов растянется на несколько часов.

Проблема в цифрах: почему последовательный цикл – это медленно

Представим три задачи разной длительности:

• Задача 1: 5 секунд.

• Задача 2: 7 секунд.

• Задача 3: 6 секунд.

Loop Over Items выполнит их одну за другой.
Общее время: 5 + 7 + 6 = 18 секунд.

Для трёх задач это не страшно. Для трёхсот, ну почти полтора часа.

Быстрое, но плохое решение: асинхронный вызов

Что если использовать узел Execute Workflow для вызова дочернего сценария и отключить опцию Wait for Subworkflow? Тогда основной процесс не будет ждать и сразу перейдёт к следующей задаче.

Проблема: главный сценарий завершится за пару секунд, но мы потеряем контроль. Непонятно, когда задачи будут выполнены, как собрать результаты и были ли ошибки. Это не автоматизация, а запуск процессов «вслепую».

Redis как диспетчер задач

Чтобы управлять параллельными процессами, нужен внешний координатор. С этой ролью отлично справляется Redis. Мы будем использовать его для двух вещей:

1. Очередь задач: список ID всех задач.

2. Флаги состояния: ключи для отслеживания статуса каждой задачи ( false, true).

Архитектура состоит из трёх сценариев: Оркестратор, Воркер и Наблюдатель.

Оркестратор (главный сценарий)
Не выполняет работу сам, а только раздаёт её:

1. Получает список задач.

2. Для каждой задачи создаёт запись в Redis: добавляет ID в очередь и ставит статус false. Нижняя ветка на скриншоте выше.

3. Вызывает дочерний сценарий-воркер (асинхронно, без ожидания).

4. Когда все задачи розданы, вызывает Наблюдателя и ждёт его завершения.

Как быстро установить Redis в ваш n8n через Coolify можете почитать у меня тут. Сам процесс установки займёт не более 5 минут. Про сам Coolify и почему он отлично сочетается с n8n писал ранее отдельный лонг.

Воркер (дочерний сценарий)
Рабочая лошадка. Его логика проста:

1. Получает на вход ID задачи.

2. Выполняет тяжёлую работу: запрашивает API, обрабатывает файлы.

3. После завершения обновляет статус задачи в Redis на done.

Наблюдатель (дочерний сценарий)
Контролёр. Его задача — дождаться завершения всех работ:

1. Получает из Redis полный список ID задач.

2. Запускает цикл проверки статусов.

3. Если хотя бы одна задача ещё в статусе false, ждёт 0,1 секунд и проверяет снова.

4. Как только все статусы – true, Наблюдатель завершает работу, а вместе с ним и Оркестратор.

Теперь мы точно знаем, когда вся партия задач обработана. Общее время выполнения равно времени самой долгой задачи, а не их сумме. Наши три задачи выполнятся примерно за 7–8 секунд вместо 18.

Скачать получившееся workflow можно здесь.

Подводные камни

• Псевдопараллельность. В стандартном режиме main n8n выполняет задачи в одном потоке. Выигрыш достигается за счёт асинхронных операций, например, ожидания ответа от API. Для реальной параллельности на уровне CPU нужен режим queue с несколькими воркерами.

• Внешняя зависимость. Redis нужно развернуть и поддерживать.

• Обработка ошибок. Если воркер упадёт, его статус останется false. Наблюдатель зациклится. Нужен механизм таймаутов или статус failed.

• Нагрузка. Не запускайте 10 000 воркеров одновременно. Группируйте задачи в пакеты по 10 - 50 штук, чтобы не исчерпать лимиты памяти сервера.

Автор, ты не пробовал подключить RabbitMQ?

Полостью согласен, всё что выше – не самый идеальный вариант реализации) Решил попробовать, такой подход, так как нагрузка на CPU не более 5% и не более 10 мб по RAM (в простое вообще по 0 в CPU/RAM). Если смотреть в сторону RabbitMQ, то там чисто на простое уже от 100 мб и какая никакая нагрузка на CPU. По сути там уже полноценный переход на event-систему контроля.

Обязательно в дальнейшем рассмотрим вариант с использованием RabbitMQ!

Вывод

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

В статусбаре в vscode – очень много всего: как полезного, так и лишнего.

Сегодня посмотрим, как можно его кастомизировать:

- Можно просто спрятать (как делаю я)

- Можно очень детально кастомизировать

- Можно перенести часть его функций в плагины

И вот тут главная фича vscode выходит наружу – у нас ведь просто браузер с html / css / js.

А значит, мы можем использовать css и js для кастомизации всего!

И оно будет работать одинаково даже в cloud версиях IDE.

В выпуске:

- Будем писать CSS для удаления лишнего из status bar

- И создавать локальные плагины на #javascript для кастомизации поведения редактора

Впереди еще пара взрывающих мозг видосов, будем и дальше превращать vscode в Черный Квадрат Малевича!

Ссылка на конфиги: https://github.com/sobolevn/the-best-python-course/tree/main...

• Во-первых, он на чистом HTML5. Это значит, что он заведется вообще на всем, хоть на телеке, хоть на холодильнике, если там есть браузер.

• Во-вторых, (для тех, кто шарит) он показывает джиттер. Если по-простому — это «дрожание» пинга. Если у вас лагает в играх или сыпется картинка на видеозвонке, а пинг при этом низкий — виноват, скорее всего, он.

• В-третьих, там есть выбор сервера, CLI (консольная утилита для админов) и даже какие-то рейтинги провайдеров. И все это без единого рекламного баннера. Не знаю, на чем они зарабатывают, но респект.

2. 2ip.ru

Ну, это классика, «олдскул». Думаю, все его знают. Это не просто спидтест, а целый комбайн: тут тебе и IP твой покажут, и на спам-листы проверят.

• Главная фишка, ради которой туда стоит лезть, — отзывы. Можно вбить свой адрес и почитать, что соседи про вашего провайдера думают. Иногда очень познавательно.

• Из минусов — он дико перегруженный. Пока найдешь нужную кнопку, сломаешь глаза об десять баннеров. Но как «справочник» по провайдерам — вещь.

3. Яндекс.Интернетометр

Этот вариант для самых ленивых. Буквально. Одна желтая кнопка на весь экран.

• Нажал, подождал 10 секунд, получил цифры. Все.

• Никакого выбора сервера, никаких джиттеров. Просто, быстро, по-яндексовски. Если нужно просто «в целом» прикинуть, сойдет.

4. Тест от вашего провайдера (Ростелеком, МТС и т.д.)

У каждого крупного провайдера есть свой измеритель. Он нужен ровно для одного: для разговора с техподдержкой.

• Когда звонишь им и жалуешься на скорость, они первым делом просят замерить «у них». Этот тест показывает скорость не до «всего интернета», а до их собственного сервера.

• Если даже на их тесте скорость ниже тарифа — это 100% их косяк, и у вас есть железобетонный аргумент. В остальных случаях они скажут, что «проблемы на внешних каналах».

Короче, итог:

• Реально померить + доп. фишки — OpenSpeedTest.ru.

• Почитать отзывы соседей — 2ip.ru.

• Нажать одну кнопку — Яндекс.Интернетометр.

• Поругаться с техподдержкой — тест на сайте провайдера.

А вы чем пользуетесь? Накидайте в комменты, может, я что-то упустил.