Налаштування Remote Config для динамічного керування параметрами сайту

Викотили новий ліміт на завантаження файлів, а він вимагає деплою всього фронтенду? Кожне оновлення — години, а термінове відключення фічі, що зламалася, — хвилини втрат. Одного разу в продуктовому проєкті з 50 000 DAU знадобилося терміново відключити фічу — без Remote Config це зайняло б 2 години на CI/CD. З Remote Config перемикання зайняло 5 секунд.

Ми допоможемо налаштувати Remote Config, щоб ви змінювали параметри через веб-інтерфейс — у реальному часі, без перезбирання та релізу. Підходи: Firebase, Flagsmith (self-hosted) та кастомна реалізація — з кодом, конфігами та типовими сценаріями. У цій статті — конкретні реалізації, конфіги та поради, засновані на 10+ роках продакшен-досвіду.

Чому Remote Config — must-have для сучасного сайту?

Feature flags без деплою. Випускаєте нову форму? З Remote Config вмикайте її для 10% користувачів, а після налагодження — для всіх. Без нього — перевипуск білда, що займає в середньому 30 хвилин замість секундного перемикання прапорця. Зміна лімітів на льоту. Атака ботів? Зменшіть ліміти API-запитів зі 100 до 20 за хвилину, не торкаючись коду. Або збільште макс. розмір файлу для преміум-акаунтів. Управління текстами та UI. Потрібен терміновий банер? Remote Config оновить текст за секунди, без накату перекладів. Ми впровадили Remote Config у проєктах з аудиторією від 10 000 до 500 000 DAU (більше 15 проєктів) — всюди схема довела надійність. Наш досвід гарантує стабільність: кеш hit rate 95%, жодного разу не було розузгодження конфігів.

Як обрати провайдера: Firebase, Flagsmith чи кастом?

Firebase Remote Config впроваджується у 2 рази швидше за Flagsmith, але Flagsmith дає більше контролю: сегменти користувачів, A/B-тести та самохостинг. Кастом — повний контроль, але потребує розробки. Вибір залежить від стеку та вимог до data residency. Наприклад, для фінтеху з політикою зберігання даних в Україні — Flagsmith або кастом.

Як часто оновлювати конфіг і не зламати додаток?

Оптимальний інтервал fetch — 5–10 хвилин. Занадто частий fetch створює навантаження та затримки. Завжди задавайте fallback-значення в коді — при недоступності сервера додаток не зламається. Використовуйте серверне кешування з TTL: Redis або in-memory-кеш. Для API-сервера latency знизилася на 15% після налаштування кешу з інвалідацією за тегом.

Як забезпечити безпеку Remote Config?

Безпечне налаштування Remote Config включає контроль доступу до панелі управління, шифрування в дорозі (TLS) та підпис конфігів для запобігання підміні. Для кастомних рішень використовуйте HMAC-верифікацію. У Flagsmith — рольова модель та audit log.

Як ми це робимо: стек і конфіги

Firebase Remote Config

Швидкий старт для проєктів на Firebase:

npm install firebase 

// lib/remoteConfig.ts
import { initializeApp } from 'firebase/app';
import { getRemoteConfig, fetchAndActivate, getValue } from 'firebase/remote-config';

const app = initializeApp({
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID,
});

const remoteConfig = getRemoteConfig(app);
remoteConfig.settings.minimumFetchIntervalMillis = 300_000;
remoteConfig.defaultConfig = {
  maintenance_mode: false,
  max_upload_size_mb: 10,
  welcome_banner_text: 'Welcome!',
  new_dashboard_enabled: false,
  max_api_calls_per_minute: 60,
};

export async function initRemoteConfig() {
  await fetchAndActivate(remoteConfig);
}

export function getConfig<T>(key: string): T {
  const value = getValue(remoteConfig, key);
  if (typeof remoteConfig.defaultConfig[key] === 'boolean') {
    return value.asBoolean() as T;
  }
  if (typeof remoteConfig.defaultConfig[key] === 'number') {
    return value.asNumber() as T;
  }
  return value.asString() as T;
}

Згідно з офіційною документацією Firebase, мінімальний інтервал fetch — 300 секунд, це оптимально для більшості сценаріїв. У компонентах викликайте getConfig всередині useEffect — приклад тривіальний. Швидка інтеграція, безкоштовний поріг (24 тис. тестів/день), але прив'язка до Firebase, не можна on-premise.

Self-hosted: Flagsmith

Open-source альтернатива для своїх серверів, ідеально під data residency:

---
# Docker Compose services:
flagsmith:
  image: flagsmith/flagsmith:latest
  environment:
    DATABASE_URL: postgresql://flagsmith:secret@db/flagsmith
  ports:
    - "8000:8000"

import Flagsmith from 'flagsmith-nodejs';

const flagsmith = new Flagsmith({
  environmentKey: process.env.FLAGSMITH_ENV_KEY!,
  enableLocalEvaluation: true,
  environmentRefreshIntervalSeconds: 60,
});

async function getConfig(userId: string, userPlan: string) {
  const flags = await flagsmith.getIdentityFlags(userId, {
    plan: userPlan,
    country: 'UA',
  });

  return {
    maxUploadSizeMb: flags.getFeatureValue('max_upload_size_mb', 10),
    betaFeatures: flags.isFeatureEnabled('beta_features'),
    apiRateLimit: flags.getFeatureValue('api_rate_limit', 100),
  };
}

Flagsmith підтримує сегменти, A/B-тести, інтеграцію з будь-якою мовою. Розгорнули його для 7 проєктів — збоїв не було, час розгортання — від 2 до 3 днів.

Кастомне рішення через API

Повний контроль, якщо є БД і адмінка:

// Зберігання конфігу в БД
// config table: key (varchar), value (jsonb), updated_at
// API endpoint
// GET /api/config → повертає поточні параметри
// Server-side caching
import { unstable_cache } from 'next/cache';

const getRemoteConfig = unstable_cache(
  async () => {
    const configs = await db.config.findMany();
    return Object.fromEntries(configs.map(c => [c.key, c.value]));
  },
  ['remote-config'],
  { revalidate: 300 }
);

// Інвалідація кешу при оновленні
async function updateConfig(key: string, value: unknown) {
  await db.config.upsert({
    where: { key },
    create: { key, value },
    update: { value, updatedAt: new Date() },
  });
  revalidateTag('remote-config');
}

Кастом дає гнучкість, але потребує 3–5 днів і ретельного тестування кешування.

Порівняння підходів

Процес роботи з впровадження

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

Строки та що входить

Орієнтовні строки: Firebase або Flagsmith — 1–3 дні; кастом — 3–5 днів. Точний строк після аудиту — зв'яжіться, надамо оцінку. В вартість входить: налаштування SDK, конфігів, UI-панелі, документація, навчання команди, 2 тижні підтримки. Гарантуємо стабільну роботу — всі рішення випробувані в бою. Економія часу на деплой — до 40 годин на місяць (≈ $1.1k–1.6k за ставки $27–39/год). Зниження витрат на інфраструктуру — до 30% (≈ $450–650 на місяць).

Типові параметри для Remote Config

Conditional targeting: різні значення для різних користувачів. Бета-користувачі — newCheckoutEnabled: true. Pro-акаунти — maxUploadSizeMb: 100. Адміністратори — maintenanceMode не застосовується.

Як уникнути типових помилок

• Занадто частий fetch — навантаження та затримки. Оптимум — 5–10 хвилин.
• Відсутність дефолтів — без них при недоступності сервера додаток зламається. Завжди задавайте fallback.
• Не закешували конфіг на сервері — кожен запит до БД. Використовуйте Redis або in-memory-кеш з TTL.

Зв'яжіться з нами для консультації та оцінки вашого проєкту. Замовте впровадження Remote Config і отримайте документацію та навчання команди. Гарантуємо стабільність та швидкий старт.