flux-lab.dev
·2 хв читання·fluxLab.dev

Чому ми обрали Go для SaaS-бекенду у fluxLab.dev

Як fluxLab.dev перейшов з Node.js на Go для продакшн SaaS-бекендів і досяг 3-кратного покращення пропускної здатності зі зниженням споживання памяті.

GoBackendSaaSАрхітектура

Вступ

У fluxLab.dev ми створюємо та підтримуємо шість продакшн SaaS-продуктів, якими користуються понад 46 000 користувачів. Коли ми почали розробляти Jobber — наш трекер пошуку роботи з ШІ — ми свідомо обрали Go замість Node.js для бекенду. Ось чому і що ми дізнались.

Проблеми Node.js на масштабі

Node.js добре нам служив для ранніх продуктів — WashFlow та EFluxCom. Але зі зростанням навантаження з'явились типові проблеми:

  • Споживання пам'яті зростало непередбачувано під навантаженням
  • CPU-інтенсивні операції (генерація PDF, парсинг відповідей ШІ) блокували event loop
  • Залежності роздували Docker-образи, уповільнюючи деплой
  • Обробка помилок в ланцюжках async/await ставала складною для трейсингу

Нам було потрібне рішення з кращими примітивами конкурентності, нижчим споживанням ресурсів та простішим деплоєм.

Чому Go?

Після оцінки Rust, Go та варіанту залишитись на Node.js з worker threads, ми обрали Go з кількох причин:

Модель конкурентності

Горутини та канали Go обробляють тисячі одночасних з'єднань з мінімальними накладними витратами. Для Jobber, де користувачі одночасно запускають парсинг вакансій через ШІ, синхронізацію календаря та обробку вебхуків — це було критично.

Компіляція та деплой

Один статичний бінарний файл. Без node_modules, без runtime-залежностей. Docker-образи зменшились з 400МБ до 12МБ. CI/CD пайплайни працюють у 4 рази швидше.

Стандартна бібліотека

Стандартна бібліотека Go покриває HTTP-сервери, роботу з JSON, криптографію та драйвери баз даних без зовнішніх залежностей. Ми використовуємо лише кілька сторонніх пакетів: pgx для PostgreSQL, chi для маршрутизації та golang-migrate для міграцій.

Обробка помилок

Явна обробка помилок у Go спочатку здавалась багатослівною, але виявилась безцінною на продакшні. Кожен шлях помилки видимий, залогований та оброблений.

Результати після 6 місяців

Порівняння Go-бекенду Jobber з аналогічними Node.js-сервісами:

  • Пам'ять: 30МБ в простої проти 180МБ (зниження в 6 разів)
  • Пропускна здатність: 12 000 запитів/с проти 4 000 на тому ж залізі
  • P99 латентність: 8мс проти 25мс для API-ендпоінтів
  • Docker-образ: 12МБ проти 400МБ
  • Холодний старт: 50мс проти 2с

Висновок

Для CPU-ефективних, легких по пам'яті бекенд-сервісів, яким потрібно надійно обробляти конкурентні навантаження, Go став очевидним вибором для fluxLab.dev. Якщо ви будуєте SaaS-продукт і впираєтесь у стіни масштабування з Node.js — Go заслуговує на серйозний розгляд.