Кастомні сценарії Make: коли стандартних модулів недостатньо

Стандартний модуль Make легко налаштовується за хвилини, але коли потрібно обробити масив із сотень замовлень, викликати кілька API в певному порядку, обробити помилки та зберегти стан між запусками — одного тригера та дії недостатньо. Наприклад, один із наших клієнтів витрачав 2 години на день на ручне вивантаження замовлень із WooCommerce в 1С. Після впровадження кастомного сценарію час скоротився до 10 хвилин, а помилки практично зникли. Економія склала близько 200 000 грн на рік за рахунок перерозподілу ресурсів. Якщо вам потрібен такий самий результат — зв'яжіться з нами, ми розробимо сценарій під вашу бізнес-логіку.

Які проблеми вирішуємо за допомогою кастомних сценаріїв?

Кастомні сценарії виходять за рамки простих тригер → дія: включають трансформацію даних, умовну логіку, виклики кількох API, ітерацію по масивах та обробку помилок. Ось типові складні задачі:

• Робота з масивами: Наприклад, підсумувати вартість всіх товарів у замовленні та застосувати знижку. Вбудовані функції map, sum, filter справляються з цим.
• Обробка помилок: Якщо API повернув 500, сценарій має повторити запит через хвилину. Ми налаштовуємо роутер за статусами відповіді та відправляємо сповіщення в Telegram.
• Виклики без модуля: Для кастомного API налаштовуємо HTTP-модуль з OAuth2, Basic Auth або API-ключем.

Обробка помилок будується так: роутер перевіряє статус HTTP-відповіді. Якщо статус 429 (Too Many Requests) — сценарій чекає 60 секунд і повторює запит. Якщо 5xx — записує помилку в Data Store і відправляє сповіщення в Telegram. Це запобігає втраті даних і спрощує моніторинг.

Чому стандартних модулів Make недостатньо для складної логіки?

Стандартні модулі розраховані на прості ланцюжки: отримати дані → обробити → відправити. Коли потрібно об'єднати дані з кількох джерел, застосувати складні фільтри або виконати транзакційні операції з відкатом при помилці, без кастомної логіки не обійтися. Кастомні сценарії дозволяють реалізувати довільну бізнес-логіку: розгалуження, цикли, очікування, виклики зовнішніх сервісів з авторизацією.

Як автоматизувати синхронізацію замовлень WooCommerce → 1С?

Задача: щогодини синхронізувати нові замовлення з WooCommerce в 1С через REST API, зі сповіщенням про помилки в Telegram. Сценарій включає:

[Schedule: щогодини]
         │
[WooCommerce: Get Orders
 status=processing
 after={{addHours(now; -1)}}]
         │
[Router]
    ├── [Фільтр: order_count > 0]
    │         │
    │   [Iterator: по кожному замовленню]
    │         │
    │   [HTTP POST: 1С API
    │    /api/orders/create]
    │         │
    │   [Router: за статусом відповіді]
    │      ├── [201: оновити WooCommerce
    │      │   meta _synced_to_1c = true]
    │      └── [Помилка: Telegram
    │          orderId + error message]
    │
    └── [Фільтр: order_count == 0]
              │
        [ігнорувати]

Кастомний сценарій Make обробляє замовлення в 3 рази швидше, ніж ручне вивантаження, і знижує кількість помилок на 90%. Економія часу дозволяє перерозподілити ресурси на більш важливі завдання. Замовте розробку такого сценарію — ми налаштуємо інтеграцію під ваші системи.

Як трансформувати дані за допомогою функцій Make?

Make має вбудовану функціональну мову для трансформацій. Ось основні інструменти:

# Рядки
{{upper(1.name)}}                           → "ІВАН"
{{substring(1.email; 0; indexOf(1.email; "@"))}}  → "ivan"
{{replace(1.phone; " "; "")}}              → "+79001234567"

# Числа
{{round(1.price * 1.19; 2)}}               → 1190.00 (з ПДВ 19%)
{{formatNumber(1.total; 2; "."; " ")}}     → "1 234 567.89"

# Дати
{{formatDate(now; "DD.MM.YYYY HH:mm")}}    → "28.03.2026 14:30"
{{addDays(1.created_at; 30)}}              → дата + 30 днів

# Масиви
{{length(1.items)}}                        → 5
{{map(1.items; "product_id")}}             → [1, 2, 3, 4, 5]
{{sum(map(1.items; "price"))}}             → сума цін

Що робити, якщо API не має готового модуля?

Для API без вбудованого модуля використовуйте кастомний HTTP з авторизацією. Приклад конфігурації OAuth 2.0 згідно з специфікацією OAuth 2.0:

{
  "type": "oauth2",
  "clientId": "{{connection.clientId}}",
  "clientSecret": "{{connection.clientSecret}}",
  "authorizeUrl": "https://api.example.com/oauth/authorize",
  "accessTokenUrl": "https://api.example.com/oauth/token",
  "scope": "read write",
  "tokenPlacement": "header",
  "tokenHeaderName": "Authorization",
  "tokenHeaderPrefix": "Bearer "
}

Робота з JSON та XML

// Parse JSON в Data Store сценарію
// Вхідний текст: '{"orders": [{"id": 1}, {"id": 2}]}'

// Використовуємо функцію parseJSON в Make
{{parseJSON(1.response_body).orders}}

// Для XML — модуль XML → JSON
// Потім працюємо як з об'єктом
{{2.root.order[].id}}

Як обробляти rate limits в Make?

Якщо API повертає 429 Too Many Requests, сценарій чекає та повторює:

[HTTP Request]
     │
[Router: статус 429]
     │
[Sleep: 60 секунд]  ←── (вбудований модуль очікування)
     │
[HTTP Request]      ←── повторна спроба

Що входить в роботу?

Ми надаємо повний цикл: аналіз вимог, проектування сценарію, реалізація з модульним тестуванням, документація, навчання вашої команди, післярелізна підтримка протягом місяця. Поетапний процес:

1. Аналіз вимог: вивчаємо вашу бізнес-логіку та інтеграції.
2. Проектування сценарію: створюємо схему з роутерами та обробкою помилок.
3. Реалізація та тестування: пишемо сценарій, перевіряємо на тестових даних.
4. Документація та навчання: готуємо інструкцію, навчаємо співробітників.
5. Підтримка: місяць безкоштовного супроводу.

Терміни та вартість

Кастомний сценарій середньої складності (10–15 модулів) — 2–4 дні. Складний з Data Store, кількома API та обробкою помилок — 1 тиждень. Вартість розраховується індивідуально — оцінимо проект після брифінгу. Наші інженери мають багаторічний досвід автоматизації в Make. Ми гарантуємо стабільну роботу сценарію та надаємо підтримку. Якщо вам потрібен надійний кастомний сценарій — зв'яжіться з нами. Отримайте консультацію та точну оцінку.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.