n8n: una bonita envoltura que se llevó dos días

Клиент пришёл с идеей: у них есть доступ к API level.travel, сотни Telegram-каналов для турагентов и желание автоматически публиковать выгодные туры по расписанию. Звучит как типичная задача на автоматизацию — бери API, забирай JSON, обрабатывай, публикуй. Я уже прикидывал как это будет выглядеть на Python, когда клиент добавил требование: использовать n8n. Команда была уверена, что это упростит поддержку в будущем — “там же всё визуально, любой разберётся”.

Я не стал спорить. Сел делать.

Два дня спустя я удалил все воркфлоу и переписал логику на Python. Ушло несколько часов.

Это не история про то, что n8n плохой инструмент вообще. Это история про то, как инструмент активно продаёт себя как решение задач, которые он на самом деле не решает — или решает настолько криво, что проще было написать код с нуля. Разберём маркетинговые мифы.

Миф 1: “Не надо писать код”

Что обещают: визуальный интерфейс заменяет программирование. Соединяешь ноды, настраиваешь поля, запускаешь. Логика есть, кода нет.

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

В проекте нужно было итерироваться по списку направлений, на каждом шаге запускать поиск туров через API и ждать результатов. API у level.travel асинхронный: отправляешь запрос, получаешь ID, потом периодически запрашиваешь статус по этому ID пока не придёт результат. Казалось бы — обычная задача, такое встречается везде.

В n8n я не смог сделать это стабильно за два дня. Цикл то терял элементы, то падал без внятной ошибки, то возвращал данные в формате который ломал следующую ноду. Дебаггинга как такового нет — запускаешь воркфлоу, смотришь что вышло, угадываешь где сломалось, что-то меняешь, запускаешь снова. Это не разработка, это гадание на JSON-гуще. С кодом когда что-то ломается — у тебя есть стектрейс, есть строка, есть переменные. В n8n у тебя есть красивая схема с зелёными галочками на одних нодах и красным крестиком на какой-то одной — и абсолютно непонятно почему именно на ней.

Миф 2: “Легко прототипировать”

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

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

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

Потому что альтернатива существует, и она быстрее.

Но главное — точка сравнения сместилась. Раньше выбор был между “n8n” и “писать всё с нуля”. Сейчас выбор между “n8n” и “попросить LLM написать код”. Я скинул задачу в Claude, получил рабочий черновик на Python за несколько минут, потратил пару часов на отладку и edge-кейсы — и всё было в проде. Это и есть быстрое прототипирование. Таскать ноды по канвасу пока дерёшься с JSON-схемами — это просто медленно, только по-другому и с худшими инструментами.

Миф 3: “Могут использовать не-разработчики”

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

Что происходит на самом деле: как только задача становится чуть сложнее линейного “получи вебхук → отправь в Slack”, нужен человек который думает как разработчик. n8n не убирает сложность — он её прячет. Не-разработчик упирается в стену, как правило в проде и в самый неудобный момент — в пятницу вечером, когда каналы не публикуют, а все уже разошлись. После этого разработчик всё равно подключается, только теперь он работает в ограниченной визуальной среде без нормального редактора, автодополнения и внятного контроля версий.

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

Миф 4: “Интеграции делаются просто”

Что обещают: сотни встроенных коннекторов. Подключить Slack, Google Sheets, Telegram, любую популярную SaaS — это несколько кликов. Не нужно писать HTTP-клиенты, не нужно читать документацию API, просто выбираешь сервис и настраиваешь.

Что происходит на самом деле: для happy path встроенных коннекторов — да, быстро. Ровно до того момента пока ты не выходишь за его пределы.

API level.travel требовал асинхронного поллинга: запустил поиск, получил ID, опрашиваешь пока не придёт результат. Готового коннектора нет, строишь руками. Это мини-цикл внутри основного цикла по направлениям — и вот тут n8n начинает разваливаться на части. Вложенные циклы в нём работают странно, данные начинают теряться или приходить не в том формате, визуальная схема превращается в спагетти из ниточек, и ты уже не понимаешь что куда идёт.

Реальные API всегда немного кривые. У них есть quirks, нестандартные edge-кейсы, пагинация которая работает не как ты ожидаешь, авторизация со своими особенностями. Код с этим справляется нормально: написал вспомогательную функцию, вызываешь где нужно, движешься дальше. В n8n каждое нестандартное поведение — это ещё один кластер нод, ещё один маппинг полей, ещё одна точка где оно может тихо сломаться.

Миф 5: “В экосистеме есть всё нужное”

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

Что происходит на самом деле: экосистема хорошо покрывает популярные SaaS — Slack, Notion, Google Sheets, Airtable, стандартные CRM. Шаг в сторону — какой-нибудь отраслевой API, нишевый сервис или что-то самописное — и коннектора нет, строишь через generic HTTP-ноду руками. А это уже код, только записанный в поля интерфейса. Как только задача выходит за периметр топовых интеграций, начинаются проблемы.

В том же проекте была задача: брать данные по дешёвым авиабилетам — город вылета, город прилёта, направление, цена — и генерировать из них картинки для постов. Красивые, с оформленным задником, готовые к публикации в Telegram. Я честно полазил по нодам n8n в поисках чего-то подходящего. Есть интеграции с AI-генерацией — OpenAI, Gemini, Leonardo — но это генерация картинки из промпта, а не вставка конкретных данных в готовый шаблон. Для второго — только сторонние платные сервисы или городить что-то через HTTP-ноду к внешнему API.

На Python это решилось за полчаса: SVG-шаблон с заранее размеченными полями, вставляешь данные, конвертируешь в PNG, отправляешь. Три понятных шага, стандартные библиотеки, никаких внешних зависимостей.

Но тут появляется следующий вопрос: а что если заказчик захочет поменять шаблон? Значит нужно где-то хранить SVG-файл на сервере так, чтобы его можно было обновить. В n8n это означает ещё один отдельный воркфлоу — для загрузки файла. Настроить передачу файла, убедиться что он сохраняется куда надо, потом передать путь к нему в основной воркфлоу. Ещё ниточки, ещё ноды, ещё точки где что-то может пойти не так. То что в нормальном коде решается одной строкой — “читай шаблон вот отсюда” — в n8n превращается в отдельный инфраструктурный проект.

Миф 6: “Логику легко переиспользовать”

Что обещают: воркфлоу можно разбить на модули, вызывать один из другого, строить переиспользуемые блоки. Это же визуальное программирование, и оно поддерживает декомпозицию.

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

В n8n “вынести в функцию” означает создать отдельный sub-workflow. Потом нужно настроить как туда передаются аргументы — это отдельная механика с полями и маппингом. Потом убедиться что внутри всё выполняется без ошибок. Потом настроить как результаты возвращаются обратно в нужном формате. Потом не забыть что если sub-workflow обновился, нужно проверить всех его вызывающих. Каждый такой “рефакторинг” — это новый кластер нод, новые ниточки, новые точки отказа.

В итоге разработчики в n8n чаще копируют логику между воркфлоу чем выносят её в общее место — просто потому что это быстрее. И именно это произошло в нашем проекте: заказчики быстро разобрались что воркфлоу для нового направления проще всего сделать копипастом уже рабочего. Удобно, пока не находится ошибка. Или пока не нужно поменять шаблон поста. Тогда выясняется что таких копий уже десять, и каждую нужно найти, открыть, поправить вручную, проверить что ничего не сломалось. Классическое “исправил в одном месте, забыл в девяти других”. А через три месяца, когда ты уже не помнишь как это всё устроено, начинается настоящий детектив — только вместо улик у тебя ниточки между нодами и никакого журнала расследования.

Что в итоге

После двух дней я удалил воркфлоу и написал логику на Python. Claude сгенерировал рабочий черновик за несколько минут, пару часов на отладку — и система работала.

Что осталось от n8n в этом проекте? Тонкая обёртка: триггер по расписанию, вызов Python-скрипта, отправка результата в Telegram. n8n как навороченный cron — это вполне нормальный сценарий использования.

Вся реальная логика — асинхронный поллинг, итерация по направлениям, фильтрация, сортировка, генерация картинок, обработка ошибок — на Python. Потому что там она и должна быть.

Когда n8n на самом деле имеет смысл

Простые линейные воркфлоу без вложенной логики: получить вебхук, что-то записать, куда-то отправить. Соединить два хорошо поддерживаемых сервиса через их стандартные API. Сделать быстрый триггер для простого действия.

Если воркфлоу помещается на один экран и в нём нет петель — n8n справится, и это честный инструмент для такой задачи.

Проблема не в самом инструменте, а в пропасти между тем что он обещает и тем что реально умеет. “Замените код визуальным интерфейсом” звучит убедительно на демо. На практике это означает: замените читаемый, тестируемый, отлаживаемый код визуальным представлением, которое сложнее понимать, сложнее дебажить и сложнее поддерживать — особенно когда тебя нет рядом.

Если задача простая — используй n8n. Если есть реальная логика — пиши код. Или попроси LLM написать его за тебя. В любом случае будет быстрее, и ты будешь понимать что происходит в своей системе.