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

Вступ

У 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 спочатку здавалась багатослівною, але виявилась безцінною на продакшні. Кожен шлях помилки видимий, залогований та оброблений. Більше жодних мовчазних відхилень promise.

Архітектурні рішення

Наш Go-бекенд побудований за принципом чистої шаруватої архітектури:

/cmd/api         → Точка входу застосунку
/internal/handler → HTTP-хендлери (тонкий шар)
/internal/service → Бізнес-логіка
/internal/repository → Доступ до бази даних (pgx)
/internal/model  → Доменні моделі
/internal/middleware → Автентифікація, CORS, rate limiting

Ключові патерни, які ми взяли на озброєння:

Патерн Repository з інтерфейсами для тестованості
Впровадження залежностей через функції-конструктори — без магії фреймворків
Передавання контексту для значень у межах запиту та скасування операцій
Структуроване логування через slog для виводу логів у форматі JSON

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

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

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

Уроки

Go не ідеальний. Ось що нас спантеличило:

Generics досі обмеженіші порівняно із системою типів TypeScript
Альтернативи ORM слабші — ми використовуємо сирий SQL із pgx, і нам так більше подобається
Фронтенд-розробникам потрібен час на адаптацію, якщо вони звикли до JavaScript всюди
Тестування вимагає більше шаблонного коду для моків порівняно з Jest

Коли ми досі використовуємо Node.js

Ми не відмовились від Node.js повністю. Наші Next.js-фронтенди й досі працюють на Node.js, а для швидких внутрішніх інструментів TypeScript залишається швидшим варіантом для прототипування. Ключовий висновок: обирати правильний інструмент під конкретне завдання.

Висновок

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

Бекенд Jobber — найбільший Go-сервіс, який ми підтримуємо; кейс Jobber розповідає про весь продукт. А якщо Go — ваша мова, ми шукаємо Go-бекенд-розробника.