Всем привет, мои дорогие

Всем привет, мои дорогие. Два дня исследовал проблему: как с помощью фронта модифицировать сценарий в Make и в n8n. Оказалось очень интересно. Предварительно поделюсь результатами — есть хорошие новости, есть плохие.

Короче, вытаскивать сами блюпринты в Make и n8n я научился — это оказалось достаточно несложно. Вы знаете, что любой сценарий — это просто блюпринт (JSON). Если мы хотим динамически им управлять, то просто меняем этот блюпринт, потому что это всего лишь набор параметров. Выглядит это примерно так: у нас есть энное количество сценариев, каждый с уникальным ID. Идеология одинаковая — что в Make, что в n8n.

Вытащить блюпринт программно, не вручную — оказалось элементарно.

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

Это не VS Code, в котором мы работаем. Убил на это кучу времени, прежде чем понял, что архитектурно оно, в принципе, так не работает.

Но хорошая новость вот в чём: какая у нас задача? Мы делаем свой фронт — какое-то приложение с интерфейсом, через который хотим настраивать наш бэкенд, где работает бизнес-логика и агенты, реализованные в Make или n8n.

И модификацию этих сценариев мы можем делать просто кодом, на сервере.

Почему это хорошо? Потому что мы пишем обычный вызов на бэкенде — на любом языке: Java, TypeScript, Python — неважно. Мы делаем это в привычной среде — в VS Code, Claude Code, Codex, в любом агенте. И главное — он видит весь код.

Что происходит на практике: берём блюпринт (это просто строка, вы видели, как он выглядит), находим нужные параметры — например, хотим поменять электронный адрес — вносим изменения, сохраняем всё это в Supabase. Потом собираем новый блюпринт и отправляем его обратно в Make или n8n — и он его отрабатывает. Всё это — достаточно просто, и главное — полностью управляемо. Потому что мы остаёмся в рамках кодового агента, у которого полный доступ ко всем слоям. Это удобно для отладки.

Плюс, вся наша инфраструктура — Supabase — продолжает работать. А когда я сначала пытался делать это внутри самого n8n или Make — да, там есть возможность писать код, но с точки зрения отладки это просто ад. Потому что система закрытая.

Когда я бился с этим кодом в Make, вообще возникло ощущение, что их модуль Make Code это маркетинговый трюк. Потому что идея в том, что мы вставляем куски кода внутрь сценария — там поток, и ИИ вроде должен помогать, но эффективно он работает только тогда, когда видит всё, что происходит на всех этапах. А тут — мы всё делаем наполовину вручную. Какие-то скриншоты, мануалы… В итоге геморрой жуткий.

Но в целом — проблема решаемая. Взять блюпринт любого сценария, модифицировать, снова запустить прямо в Make — это реально. И, как оказалось, несложно. То же самое и в n8n — но с оговоркой.

Я пробовал сделать это в n8n в их облаке — и там трюк сработал. А вот в self-hosted варианте — не сработал. Хотя метод тот же. Видимо, архитектурно они там всё по-другому устроили. Вроде бы self-host — это когда вы ставите систему себе, например, как показывали в Hostinger — но на самом деле это не одно и то же. Там куча подводных камней.

Очевидно, что зарабатывают они на том, что платные версии дают больше опций. А в self-host нужно самому всё настраивать, и это куча головной боли. Но всё реально — просто нужно потратить время.

Сейчас я хочу попробовать всё это реализовать сначала в Make, потому что там проще, дешевле и доступнее. Идеология примерно та же, что в n8n, но в Make проще стартовать.

Двигаюсь дальше: собираюсь реализовать это программно — в привычной для нас среде разработки, в VSCode. С помощью кодового агента пишем управляющий код, делаем фронт-интерфейс, через который всё управляем и контролируем. И он будет интегрирован с Make — не в том смысле, что просто запускает сценарий (это мы уже делали пару месяцев назад), а в том, что мы берём нужный сценарий, модифицируем его на лету, и потом запускаем уже изменённый вариант.