MVP без n8n: когда конструктор сценариев можно пока не ставить

Каждый раз, когда речь заходит про автоматизацию для соло-билдера, первым делом всплывает n8n. Логика понятная: визуальный конструктор, сотни готовых нод, быстрый старт. Я и сам держал его в первой версии архитектуры. А потом убрал — до того, как написал первую строчку кода.

Рассказываю, как я к этому пришёл и какой проверки хватило.

Контекст: что я собирал

Система под закупку рекламы в Telegram и VK. Цепочка простая на словах: собрать данные о каналах, отобрать площадки, оформить закупку, промаркировать креативы в ОРД, свести статистику по размещениям. Плюс регулярные фоновые задачи — обновление метрик, проверка статусов, сбор отчётов.

Классический сценарий для оркестратора. Так я и планировал: n8n на VPS, воркфлоу под каждый кусок, Postgres рядом.

Проверка, которая заняла полчаса

Прежде чем ставить сервис, я выписал все внешние системы, с которыми предстоит работать: TGStat, Telemetr.io, Telega.in, TeleTarget, маркет-платформа VK, ОРД. Дальше открыл каталог нод n8n и поискал каждую по названию.

Готовых нод нет ни для одной.

Это ключевой момент. Отсутствие ноды означает, что вся работа с API ложится на меня: авторизация, пагинация, обработка лимитов, ретраи, разбор кодов ошибок, приведение ответов к своему формату. Тот же самый HTTP-код я напишу в любом случае. Вопрос только в том, где он будет жить.

Что остаётся от конструктора, если нод нет

В n8n такой код селится в Code-нодах и HTTP Request-нодах. Получается вот что:

• Логика внутри JSON-воркфлоу. Диффы в git читать больно, ревьюить самому себе — тоже. Питоновский модуль на 80 строк я перечитаю за минуту.
• Тесты почти невозможны. Запустить функцию из Code-ноды локально с моковым ответом API — отдельное упражнение.
• Лишний сервис на VPS. Ещё один контейнер, ещё одна база под его состояние, ещё один компонент, который может упасть в три ночи.
• Свой синтаксис выражений. Каждая мелочь вроде преобразования даты требует вспоминать, как это делается именно тут.

Выгода от визуальной схемы при этом почти нулевая: на картинке я вижу коробочки с надписью «Code», содержимое которых всё равно надо открывать.

Чем заменил

Тонкий Python-оркестратор. Ядро — машина состояний на Postgres:

• таблица задач со статусом, попытками и временем следующего запуска;
• воркер в цикле забирает готовые задачи и вызывает нужный обработчик;
• обработчик — обычная функция, принимает данные, возвращает следующий шаг;
• всё поднимается одной командой через Docker Compose.

По объёму кода это несколько сотен строк. Взамен я получаю нормальный git, обычные тесты, привычный дебаггер и один сервис вместо двух. Ретраи и идемпотентность всё равно пришлось бы продумывать вручную — конструктор от этой работы не освобождает.

Что я теряю осознанно

Честный список минусов:

• Визуальной схемы нет. Показать заказчику картинку «как всё устроено» теперь нужно отдельным усилием.
• Готовые ноды для популярных сервисов (Google Sheets, почта, мессенджеры) я потерял вместе с n8n. Если завтра понадобится их пять штук — я об этом пожалею.
• Хранение ключей и запуск по расписанию пришлось решать самому. Решается за вечер, но время потрачено.

Когда n8n стоит ставить

Я говорю про конкретный проект. Ситуации, где конструктор выигрывает, никуда не делись:

• Большинство интеграций есть в каталоге. Тогда экономия огромная — вы кликаете вместо того, чтобы писать клиент к API.
• Сценарии правят люди без кода. Маркетолог сам поменяет ветку в воркфлоу, в питоновский модуль он не полезет.
• Нужен прототип на выброс. Проверить гипотезу за вечер и выкинуть — n8n тут вне конкуренции.
• Вы внутри крупной компании. Продукт сейчас явно движется в корпоративный сегмент: раунд на 180 млн долларов и партнёрство с SAP по визуальной оркестрации ИИ-воркфлоу говорят сами за себя.

Чек-лист перед установкой

Пять вопросов, которые я теперь задаю до того, как поднимать любой оркестратор:

1. Сколько моих интеграций закрывается готовыми нодами? Меньше половины — повод задуматься.
2. Кто будет править сценарии через полгода? Если только я — визуальный редактор избыточен.
3. Как я буду это тестировать и катить через git?
4. Сколько сервисов добавится на сервер и кто их чинит?
5. Что я сделаю, когда упрусь в ограничение конструктора? Переписывать на код с нуля дороже, чем сразу начать с кода.

Вывод

n8n — хороший инструмент, который решает конкретную задачу: склеить сервисы, для которых у него есть коннекторы. Когда коннекторов нет, он превращается в интерфейс поверх вашего же кода плюс лишний контейнер.

Поэтому на этапе MVP я советую начинать с проверки каталога нод. Полчаса на поиск шести названий сэкономили мне неделю возни с чужой абстракцией. Добавить конструктор потом, когда интеграции из каталога реально понадобятся, гораздо проще, чем выковыривать логику из JSON-воркфлоу.