Рефакторинг n8n:
как сократить воркфлоу с 15 до 9 нод

Зачем вообще рефакторить рабочий воркфлоу

Кстати, хороший вопрос. Воркфлоу работает. Запускается в 7 утра, присылает брифинг, помечает события как отправленные. Зачем трогать?

Три причины:

1. Дебаг. Когда что-то ломается (а оно ломается - мы это только что пережили), вы ищете проблему в 15 местах. В 9 местах - быстрее
2. Понимание. Через 3 месяца вы откроете этот воркфлоу и увидите "Get Dates Morning", "Build Morning Data", "Build Morning Context" - три ноды подряд. И спросите: а почему они разделены? Ответ: потому что так получилось. Не потому что так правильно
3. Расширение. Хотите добавить Google Calendar как источник событий? С 15 нодами это ещё одна ветка, ещё один merge. С 9 нодами - просто дополнительный блок в одной ноде

Экономия 5 секунд на воркфлоу, который запускается раз в день в 7 утра, пока вы спите - ноль ценности. Упрощение ради дебага и понимания - реальная ценность

Текущая архитектура: 15 нод

Schedule 07:00
  ↓
Get Dates Morning         ← Code: вычисляет today, tomorrow
  ↓
Read Events Sheet         ← HTTP: Google Sheets API
  ↓
Build Morning Data        ← Code: фильтрует события
  ↓
Read Calendar Events      ← HTTP: Google Calendar (отключена)
  ↓
Merge Calendar + Sheet    ← Code: мержит два источника
  ↓
Build Morning Context     ← Code: собирает промпт + французские слова
  ↓
GPT Morning Brief         ← HTTP: OpenAI API
  ↓
Merge Morning GPT         ← Code: вставляет слова в ответ + sanitize HTML
  ↓
Send Morning Brief        ← HTTP: Telegram
  ↓
Build Notified Payload    ← Code: формирует JSON
  ↓
Mark Today Notified       ← HTTP: Google Sheets batchUpdate
  ↓
Check Advance Events      ← Code: проверяет 48ч вперед
  ↓
Send Advance Alert        ← HTTP: Telegram
  ↓
Mark Advance Flags        ← HTTP: Google Sheets batchUpdate

Смотрите на это. 6 Code-нод, 6 HTTP-нод, 1 Schedule, 1 отключённая нода, 1 merge. Из 6 Code-нод - четыре идут подряд в начале цепочки. Каждая берёт выход предыдущей и делает следующий шаг подготовки данных

Это как четыре повара, которые по очереди солят один суп. Может справиться один

Целевая архитектура: 9 нод

Schedule 07:00
  ↓
Read Events Sheet         ← без изменений
  ↓
Prepare Context           ← НОВАЯ: даты + фильтрация + контекст + промпт
  ↓
GPT Morning Brief         ← промпт уже содержит все данные
  ↓
Send Morning Brief        ← sanitizeTgHtml встроена
  ↓
Mark Today Notified       ← payload через expression
  ↓
Check Advance Events      ← без изменений
  ↓
Send Advance Alert        ← без изменений
  ↓
Mark Advance Flags        ← без изменений

Что убираем и почему

Что НЕ трогаем

Что создаём

Главное правило: исследование до кода

Вот конкретный чек-лист - что проверить перед тем, как написать первую строку:

• Прочитать Get Dates Morning - как вычисляются даты? Учитывается ли timezone?
• Прочитать Build Morning Data - как фильтруются события? Что если событий 0?
• Прочитать Build Morning Context - какой массив французских слов? Менялся ли он вручную?
• Прочитать Merge Morning GPT - как именно вставляются слова? Где sanitize?
• Проверить: какие данные передаются между нодами? Какие поля используются дальше?
• Проверить: есть ли кастомизации, которые пользователь делал руками?
• Убедиться: текущая версия проходит тест SUCCESS перед началом изменений

Почему это важно? Потому что в Build Morning Context может лежать массив из 30 дней французских слов, который редактировали вручную. Или в Build Morning Data может быть фильтр, который обрабатывает recurrence-правила для еженедельных событий. Потеряете нюанс при объединении - воркфлоу будет работать, но неправильно. А заметите это через неделю

Риски и как их снизить

Вероятность что заработает с первого раза: 70-75%.

Не 100% - потому что 4 Code-ноды, которые объединяются, содержат скрытую логику. Не 50% - потому что задача простая: прочитать, отфильтровать, отправить

Как снизить риск:

• Сохранить оригинал. Перед рефакторингом - скопировать весь воркфлоу (через n8n API или Duplicate). Если что-то пойдет не так - откатиться за 10 секунд
• Тестировать на реальных данных. Не на моках. Реальная таблица, реальные события, реальный Telegram. Мок-тест покажет "всё ок", а потом в продакшене GPT получит пустой промпт
• Не трогать французские слова. Если массив кастомизирован - перенести как есть. Не генерировать через GPT, не "улучшать". Детерминистичный список лучше рандомного

Когда НЕ стоит делать рефакторинг

Кстати, знаете что? Иногда ответ - "не трогай"

• Воркфлоу работает, не ломается, не нужно расширять? Не трогайте
• Экономия только в секундах, а запуск раз в день? Не трогайте
• Нет времени на полное исследование всех Code-нод? Точно не трогайте

Рефакторинг оправдан когда: нужно добавить новый источник данных (Calendar), часто ломается и долго дебажить, или архитектура мешает понять что происходит

В нашем случае все три причины на месте. Но мы всё равно сначала исследуем, потом делаем. Не наоборот

FAQ