Автоматизация под ключ на своём коде: когда MVP обходится без n8n

Когда я собирал research по стеку для marketing-automation MVP, n8n выглядел очевидным выбором. Соло-билдер, нужна скорость, визуальный конструктор — всё сходится. Но чем глубже я лез в конкретные интеграции проекта, тем сильнее это ощущение разваливалось. В итоге я убрал n8n из стека ещё до первой строчки кода. Ниже — почему и что встало на его место.

Почему n8n здесь не окупается

n8n продаёт скорость через готовые ноды: перетащил блок, подключил, поехали. Экономия появляется, когда у сервиса, с которым ты работаешь, эта нода уже есть.

Теперь список ключевых интеграций моего проекта: TGStat, Telemetr.io, Telega.in, TeleTarget, VK маркет-платформа, ОРД. Готовых нод под них в n8n нет. Ни одной. Это значит, что каждый вызов я всё равно пишу руками — HTTP-запрос, авторизация, парсинг ответа, обработка ошибок. В n8n такой код живёт внутри Code-нод.

Получается забавная штука. HTTP-логику я пишу в любом случае. Разница только в том, что n8n сверху навешивает UI-обёртку и требует отдельный сервис на VPS: сам инстанс, его база, его обновления, его память. Я плачу инфраструктурой и лишним слоем за визуализацию кода, который и так мой.

Для соло-билдера это плохая сделка. Отладка Code-нод через веб-интерфейс медленнее, чем обычный python -m pytest. Версионировать флоу в git неудобно. А когда что-то падает в 3 часа ночи, я хочу читать стектрейс, не кликать по канвасу.

Что встало вместо: тонкий оркестратор

Ядро MVP — простая машина состояний на Postgres. Не фреймворк, не движок воркфлоу. Таблица задач, у каждой задачи статус, и Python-цикл, который двигает задачи по статусам.

Архитектура получилась из четырёх кусков:

• Оркестратор — Python-процесс. Читает очередь задач из Postgres, вызывает нужный коннектор, пишет результат обратно, двигает статус. Вся логика повторов и таймаутов живёт тут же.
• Коннекторы — по одному тонкому модулю на каждый внешний API (TGStat, Telega.in, ОРД и остальные). Каждый умеет ровно то, что нужно проекту, без универсальности на будущее.
• Postgres — единый источник правды. Состояние задач, кэш ответов, логи запусков. База уже нужна проекту, так что отдельного стора под очередь я не завожу.
• Docker Compose — два сервиса: оркестратор и Postgres. Поднимается одной командой, переносится на любой VPS без плясок.

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

Фазовый план

Я разбил сборку на фазы, чтобы каждая давала работающий результат.

1. Скелет. Docker Compose, Postgres со схемой задач, пустой цикл оркестратора. Задача проходит статусы вручную — проверяю, что механика движется.
2. Первый коннектор. Беру одну интеграцию (обычно ту, где данных больше всего) и прогоняю её через оркестратор от начала до конца. Тут вылезают все реальные грабли API: лимиты, форматы, авторизация.
3. Остальные коннекторы. По образцу первого. Каждый — отдельный модуль с парой тестов на разбор ответа.
4. Надёжность. Повторы, backoff, алерты на застрявшие задачи. То, без чего MVP переживёт демо, но не переживёт неделю в бою.
5. ОРД и отчётность. Маркировка и выгрузки — отдельно, потому что цена ошибки тут выше и требования жёстче.

Когда n8n всё-таки берут

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

Мой случай другой. Соло-разработчик, кастомные API без нод, желание держать всё в git и читать логи привычным способом. Здесь тонкий Python-оркестратор проще в сборке, дешевле в эксплуатации и честнее по количеству движущихся частей.

Вывод, который я забрал себе: прежде чем ставить оркестратор ради скорости, посчитайте, сколько интеграций он реально ускорит. Если готовых нод под ваши сервисы нет, скорость превращается в лишний сервис на VPS поверх кода, который вы всё равно напишете сами.