Основные узкие места могут быть такие: вебхуки n8n (если один инстанс и без queue-mode), сами вызовы к LLM (скорость ответа и лимиты провайдера) и база Supabase (много мелких запросов, отсутствие индексов). Для масштабирования можно сделать так: включить queue-mode в n8n с Redis и поднять несколько worker-инстансов, вынести webhook-инстанс отдельно от воркеров. Затем можно снизить количество сохраняемых execution-логов (сохранять только воркфлоу, упавшие с ошибкой), сэкономим память. В ветках с AI-агентом как минимум настроить логику retry, и хотя бы одну Fallback модель. На стороне Supabase - обязательные использовать индексы по часто фильтруемым колонкам. И по возможности задействовать, кэш (Redis) для "горячих" данных, чтобы n8n вообще поменьше ходил в БД.
Масштабировать можно, и с точки зрения разработки, и с точки зрения железа (например, n8n можно запускать в режиме worker, за счет чего нагрузка будет распределяться).
У меня есть коллега, у которого несколько проектов крутятся в проде, так что если кратко - масштабировать можно.
Да, быстрые MVP разворачивать прям самое то. Причем и в проде он тоже может неплохо рабоать с одной стороны, а с другой стороны - на питон при желании можно быстро перекинуть воркфлоу (Cursor либо Claude Code + базовые навыки вайбкодинга)
Согласен. При чем интересно, что были уже инструменты такие как Make, Zapier, но n8n как инструмент построения автоматизаций просто взрывает рынок. Думаю, то, что это опенсорс, сильно повлияло.
Мне кажется действительно тренд сейчас будет идти по нарастающей, потом спустя какое-то время выйдет на плато.
Причем, что интересно, с точки зрения развития технических систем тренд к автоматизации это не новшество. Это уже происходило во многих хозяйственных сферах (первое что приходит на ум: переход от ручного труда к конвеерам, роботизация в производстве, появление комабйнов в сельхоз отрасти и тд), т.е. само стремление к автоматизации существовало всегда.
Я думаю, что такой стремительный рост вызван тем, что во первых, сам тренд уже существовал, а во вторых - сейчас появились доступные инструменты для создания автоматизаций для большого количества людей (появление LLM, которое нашло свое применение в автоматизации написания кода, появился n8n, которым можно автоматизировать кучу процессов вообще с минимальным написанием кода).
Так что предполагаю, что то, что мы сейчас еще делаем руками, спустя некоторое время, будет автоматизированно. В том числе с использованием того, что рассматривается в статье.
Интересный вопрос! Спасибо что спросили) Сами по себе конфликты возникают, если в одной и той же строке кода были сделаны изменения, и при этом, эти изменения расходятся. В самом простом и идеальном случае, если черри-пикнуть из feature ветки коммит в main, затем добавить еще коммитов в feature, после чего смерджить, то конфликтов возникнуть не должно, так как bugfix-коммит в feature ветке и bugfix-коммит в main ветке будут содержать идентичные изменения. Но это в идеально случае. В реальности же, вероятнее всего, конфликты могут быть, просто потому что те же самые строки впоследствие могут быть снова изменены в ветке feature. На черри-пик коммит в этом случае можно смотреть просто как на коммит, который кто-то сделал в ветке main. И если ваши финальные изменения, которые мерджатся из ветки feature никак не конфликтуют с изменениями в коммитах main, то все будет ок.
Решил для верности потестировать (репо): - мердж ветки feature прошел с конфликтом из-за того, что нечаянно где-то тронул пустые строки (дифф) - мердж ветки feature_2 прошел без конфликтов (тот самый "идеальный" случай) - мердж ветки feature_3 прошел с конфликтом, так как в финальных изменениях ветки feature "перезаписывались" те же строчки кода, которые ранее были перенесены коммитом в main (дифф).
На всю историю репозитория удобнее всего посмотреть во вкладке Repository graph
Последние два уже прошел, а вот первый только начал, супер полезно.
Сто процентов!
Да, для этого имхо лучше всего подходит.
По сути тот же самый postgres, просто в облаке. Удобно, что не надо на сервере разворачивать, и удобная админка.
Основные узкие места могут быть такие: вебхуки n8n (если один инстанс и без queue-mode), сами вызовы к LLM (скорость ответа и лимиты провайдера) и база Supabase (много мелких запросов, отсутствие индексов). Для масштабирования можно сделать так: включить queue-mode в n8n с Redis и поднять несколько worker-инстансов, вынести webhook-инстанс отдельно от воркеров. Затем можно снизить количество сохраняемых execution-логов (сохранять только воркфлоу, упавшие с ошибкой), сэкономим память. В ветках с AI-агентом как минимум настроить логику retry, и хотя бы одну Fallback модель. На стороне Supabase - обязательные использовать индексы по часто фильтруемым колонкам. И по возможности задействовать, кэш (Redis) для "горячих" данных, чтобы n8n вообще поменьше ходил в БД.
Не пожалеешь)
Масштабировать можно, и с точки зрения разработки, и с точки зрения железа (например, n8n можно запускать в режиме worker, за счет чего нагрузка будет распределяться).
У меня есть коллега, у которого несколько проектов крутятся в проде, так что если кратко - масштабировать можно.
Полезно, спасибо!
Видел результаты выпускников, очень крутые автоматизации делают ребята.
Удобно получается, и по фукнциональности круче, чем обычное облако. Роман топ, спасибо за подгон!
Да, быстрые MVP разворачивать прям самое то. Причем и в проде он тоже может неплохо рабоать с одной стороны, а с другой стороны - на питон при желании можно быстро перекинуть воркфлоу (Cursor либо Claude Code + базовые навыки вайбкодинга)
Согласен. Они по сути дают относительно простой способ внедрять ИИ в процессы, и тут грех не воспользоваться))
Согласен. При чем интересно, что были уже инструменты такие как Make, Zapier, но n8n как инструмент построения автоматизаций просто взрывает рынок. Думаю, то, что это опенсорс, сильно повлияло.
Мне кажется действительно тренд сейчас будет идти по нарастающей, потом спустя какое-то время выйдет на плато.
Причем, что интересно, с точки зрения развития технических систем тренд к автоматизации это не новшество. Это уже происходило во многих хозяйственных сферах (первое что приходит на ум: переход от ручного труда к конвеерам, роботизация в производстве, появление комабйнов в сельхоз отрасти и тд), т.е. само стремление к автоматизации существовало всегда.
Я думаю, что такой стремительный рост вызван тем, что во первых, сам тренд уже существовал, а во вторых - сейчас появились доступные инструменты для создания автоматизаций для большого количества людей (появление LLM, которое нашло свое применение в автоматизации написания кода, появился n8n, которым можно автоматизировать кучу процессов вообще с минимальным написанием кода).
Так что предполагаю, что то, что мы сейчас еще делаем руками, спустя некоторое время, будет автоматизированно. В том числе с использованием того, что рассматривается в статье.
Интересный вопрос! Спасибо что спросили) Сами по себе конфликты возникают, если в одной и той же строке кода были сделаны изменения, и при этом, эти изменения расходятся. В самом простом и идеальном случае, если черри-пикнуть из feature ветки коммит в main, затем добавить еще коммитов в feature, после чего смерджить, то конфликтов возникнуть не должно, так как bugfix-коммит в feature ветке и bugfix-коммит в main ветке будут содержать идентичные изменения. Но это в идеально случае.
В реальности же, вероятнее всего, конфликты могут быть, просто потому что те же самые строки впоследствие могут быть снова изменены в ветке feature.
На черри-пик коммит в этом случае можно смотреть просто как на коммит, который кто-то сделал в ветке main. И если ваши финальные изменения, которые мерджатся из ветки feature никак не конфликтуют с изменениями в коммитах main, то все будет ок.
Решил для верности потестировать (репо):
- мердж ветки feature прошел с конфликтом из-за того, что нечаянно где-то тронул пустые строки (дифф)
- мердж ветки feature_2 прошел без конфликтов (тот самый "идеальный" случай)
- мердж ветки feature_3 прошел с конфликтом, так как в финальных изменениях ветки feature "перезаписывались" те же строчки кода, которые ранее были перенесены коммитом в main (дифф).
На всю историю репозитория удобнее всего посмотреть во вкладке Repository graph
Спасибо за дополнение!
Неплохо...🤔
Переодень ее