Як замінити Zapier і Make: пишемо мікросервіси на Node.js для Google Workspace

Zapier/Make зручні, поки у вас “пару сценаріїв” і невеликий обсяг даних. Але як тільки автоматизація стає регулярною частиною бізнесу (ліди, звіти, документи, алерти), з’являється “податок на автоматизацію”: ви платите не за цінність, а за кількість тасків/операцій. І найболючіше — ці витрати ростуть разом із вашим ростом.

Альтернатива — self-hosted мікросервіси на Node.js, які приймають webhooks, ходять у Google Workspace API через OAuth 2.0 або Service Account, обробляють JSON і віддають результат назад у Sheets/Gmail/Drive. Без зайвих “конекторів” і без абонплати за кожну дію.

Економіка: коли SaaS стає дорожчим за власний сервіс

У Zapier/Make модель проста: чим більше автоматизацій і даних — тим більше ви платите. Для малого бізнесу це ок, але для команд із системною звітністю/інтеграціями суми швидко стають “золотими”.

У self-hosted підході ви платите інакше:

• Хостинг: VPS за $5–10/міс або serverless (Cloud Run/Functions) з оплатою за фактичне використання.
• Контроль: ви самі визначаєте, що є “таском”, а що — просто обробкою даних у вашому коді.
• Масштабування: не купуєте “план з лімітами”, а додаєте ресурси точково.

На практиці, якщо у вас:

• щоденні/щогодинні синхронізації,
• багато рядків у Google Sheets,
• кілька джерел даних (CRM, реклама, пошта, форми),

…то Node.js сервіс часто окупається за 1–2 місяці лише за рахунок економії на SaaS-підписках.

Архітектура рішення: мінімальний “скелет” мікросервісів

Ось робочий патерн, який легко підтримувати роками.

1) Webhooks як вхідні “сигнали”

Мікросервіс піднімає HTTP endpoint, наприклад:

• /webhook/lead — новий лід,
• /webhook/report — час оновити звіт,
• /webhook/file — файл додано в папку.

Це може бути як подія з вашої CRM/сайту, так і тригер з Google Apps Script.

2) Взаємодія з Google Cloud Platform (GCP)

У Google Cloud Console ви створюєте:

• Project
• увімкнені API (Sheets API, Gmail API, Drive API)
• креденшіали (OAuth 2.0 Client або Service Account)
• Secret Manager (щоб не зберігати ключі в коді)

3) Google Auth Library / Google SDK

У Node.js стандартний шлях — google-auth-library + googleapis (Google SDK):

• або OAuth 2.0 (коли працюєте від імені користувача),
• або Service Account (коли сервіс працює “від системи” і має доступ до файлів/таблиць через шаринг).

4) Асинхронність Node.js = ідеально для інтеграцій

Node.js сильний там, де багато I/O: REST API запити, читання/запис, черги, ретраї. Неблокуючий ввід-вивід і асинхронні функції дозволяють одночасно обробляти багато подій без “зависань”.

Технічна реалізація (обзорно): “прийняв → обробив → записав у Sheets”

Нижче — мінімальний приклад: приймаємо webhook, парсимо JSON, пишемо рядок у таблицю через Google Sheets API.

import express from "express";
import { google } from "googleapis";

const app = express();
app.use(express.json());

// Service Account credentials (краще брати з Secret Manager)
const auth = new google.auth.GoogleAuth({
  scopes: ["https://www.googleapis.com/auth/spreadsheets"],
});

app.post("/webhook/report", async (req, res) => {
  try {
    const payload = req.body; // JSON
    const sheets = google.sheets({
      version: "v4",
      auth,
    });

    // Приклад: додаємо рядок у Google Sheet
    await sheets.spreadsheets.values.append({
      spreadsheetId: process.env.SHEET_ID,
      range: "Report!A:D",
      valueInputOption: "USER_ENTERED",
      requestBody: {
        values: [[new Date().toISOString(), payload.source, payload.metric, payload.value]],
      },
    });

    res.json({ ok: true });
  } catch (e) {
    console.error(e);
    res.status(500).json({ ok: false, error: String(e) });
  }
});

app.listen(process.env.PORT || 8080);

Що важливо

1. endpoint працює як REST API
2. приймає webhooks (події)
3. обробляє дані як JSON
4. використовує Google Workspace API через Google SDK

Безпека і масштабованість: чому “своє” часто безпечніше

SaaS-конектори — це третя сторона, куди “протікають” дані. Навіть якщо вони надійні, у вас з’являється зайвий контур ризику.

У власному сервісі ви контролюєте:

• де лежать ключі (Secret Manager, env vars),
• хто має доступ (IAM),
• що логувати (без персональних даних),
• як робити ретраї, rate limit і backoff.

Практичні поради

• не тримайте API-ключі в репозиторії (ніколи),
• підписуйте webhooks (HMAC) або ставте auth token у заголовок,
• додавайте rate limiting на вході,
• використовуйте чергу (наприклад, Pub/Sub) для піків навантаження.

Node.js vs “просто скрипти”: де межа?

Якщо у вас 1–2 прості сценарії — інколи Apps Script достатньо. Але коли з’являється:

• кілька джерел даних,
• складна бізнес-логіка,
• потреба у стабільності та логуванні,
• інтеграції з зовнішніми сервісами,

…то мікросервісна архітектура дає кращу підтримку і масштабованість.

Коли переходити на своє рішення, а коли залишити SaaS

Обирайте self-hosted Node.js мікросервіси, якщо:

• витрати на Zapier/Make ростуть щомісяця разом із кількістю операцій,
• потрібні кастомні правила (валідація, дедуплікація, складні трансформації),
• важливий контроль доступів і безпеки,
• потрібна стабільна інтеграція з Google Workspace API та іншими REST API.

Залишайте SaaS, якщо:

• сценарії рідкісні і прості,
• вам важливо “зробити за 30 хв без розробника”,
• немає потреби у логуванні/контролі/масштабуванні.

Якщо потрібна допомога з проєктуванням або впровадженням (OAuth 2.0, webhooks, Google Cloud Console, безпечне зберігання секретів), я зазвичай рекомендую починати з малого “пілотного” сервісу і вже потім нарощувати. У таких кейсах можуть стати в пригоді послуги з налаштування API-інтеграцій як приклад зовнішнього експертного ресурсу для швидкого старту без хаосу.