Backend for Frontend (BFF): прискорюємо мобільні та веб-застосунки

Мобільний застосунок робить 5–10 послідовних HTTP-запитів для завантаження однієї сторінки. На мобільній мережі кожен round trip додає 200–500 мс — сумарно до 2–3 секунд. Типовий сценарій: /users/{id}, /orders?userId={id}&limit=3, /notifications/unread, /recommendations?userId={id}, /loyalty/points/{id}. Клієнт повинен сам дочекатися всіх відповідей і виконати трансформацію. Це не тільки повільно, але й споживає зайвий трафік: завантаження непотрібних полів (наприклад, повної адреси при перегляді кошика) збільшує обсяг переданих даних на 30–50%. Економія на трафіку та інфраструктурі може досягати 40% після впровадження BFF. Ми пропонуємо впровадити проміжний шар Backend for Frontend (BFF).

BFF — це окремий бекенд-сервіс, створюваний під конкретний тип клієнта (веб, мобільний застосунок, Smart TV). Він приймає один запит від клієнта, паралельно звертається до необхідних мікросервісів, агрегує дані, відсікає зайве і повертає результат у форматі, оптимальному для даного клієнта. Концепція детально описана в статті Мартіна Фаулера Backend for frontend.

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

• N+1 запит і затримки. Типова картина: 5–10 послідовних викликів для однієї сторінки. BFF скорочує це до одного виклику, виконуючи паралельні запити до сервісів. Економія часу — до 80% round trips.
• Надлишкові дані. Мікросервіс віддає поля, не потрібні клієнту (наприклад, адресу при перегляді кошика). BFF відсікає зайве, знижуючи обсяг переданих даних на 30–50%.
• Складна автентифікація. JWT, refresh token, httpOnly cookie — BFF керує сесіями централізовано, не розкриваючи доступ до сервісів з клієнта.
• Часткові збої. Якщо один сервіс недоступний, BFF може повернути часткову відповідь (null для фрагменту, що впав) замість помилки 500.
• Кешування спільних даних. Розміщення BFF між клієнтом і сервісами дозволяє кешувати агреговані відповіді (наприклад, рекомендації), знижуючи навантаження на мікросервіси на 40%.

Як ми реалізуємо BFF: стек і приклади

На практиці BFF зручно будувати на Node.js з Express або Apollo Server (GraphQL). У проектах ми використовуємо Node.js, TypeScript, Express або Apollo Server, Redis для кешування (ioredis), axios для HTTP-запитів.

Приклад для мобільного застосунку

Потрібен один ендпоінт /mobile/dashboard, який повертає профіль, останні замовлення, сповіщення та бали лояльності.

// mobile-bff/routes/dashboard.ts
router.get('/mobile/dashboard', authenticate, async (req, res) => {
  const userId = req.user.id;

  const [userResult, ordersResult, notificationsResult, loyaltyResult] =
    await Promise.allSettled([
      userService.get(`/users/${userId}`),
      orderService.get(`/orders?customerId=${userId}&limit=3&fields=id,status,total,createdAt`),
      notificationService.get(`/notifications/${userId}/unread-count`),
      loyaltyService.get(`/loyalty/${userId}/summary`)
    ]);

  const response = {
    user: userResult.status === 'fulfilled' ? {
      id: userResult.value.data.id,
      name: userResult.value.data.displayName,
      avatar: userResult.value.data.avatarUrl
    } : null,
    recentOrders: ordersResult.status === 'fulfilled'
      ? ordersResult.value.data.items.map(transformOrderForMobile)
      : [],
    unreadCount: notificationsResult.status === 'fulfilled'
      ? notificationsResult.value.data.count
      : 0,
    loyalty: loyaltyResult.status === 'fulfilled' ? {
      points: loyaltyResult.value.data.balance,
      tier: loyaltyResult.value.data.tier
    } : null
  };

  res.json(response);
});

Приклад для веб-клієнта

Веб-клієнту потрібні ті самі дані, але з повним профілем, більшим списком замовлень та аналітикою.

// web-bff/routes/dashboard.ts
router.get('/web/dashboard', authenticate, async (req, res) => {
  const userId = req.user.id;

  const [user, orders, stats, notifications] = await Promise.allSettled([
    userService.get(`/users/${userId}`),
    orderService.get(`/orders?customerId=${userId}&limit=10`),
    analyticsService.get(`/analytics/user/${userId}/stats`),
    notificationService.get(`/notifications/${userId}?limit=5&unread=true`)
  ]);

  res.json({
    user: user.status === 'fulfilled' ? user.value.data : null,
    orders: orders.status === 'fulfilled' ? orders.value.data : { items: [], total: 0 },
    analytics: stats.status === 'fulfilled' ? stats.value.data : null,
    notifications: notifications.status === 'fulfilled' ? notifications.value.data : []
  });
});

// web-bff/graphql/schema.ts
const typeDefs = gql`
  type Query {
    dashboard: Dashboard!
    order(id: ID!): Order
  }

  type Dashboard {
    user: User!
    recentOrders: [Order!]!
    stats: UserStats!
  }
`;

const resolvers = {
  Query: {
    dashboard: async (_, __, { userId }) => {
      const [user, orders, stats] = await Promise.all([
        userService.getUser(userId),
        orderService.getRecentOrders(userId),
        analyticsService.getUserStats(userId)
      ]);
      return { user, recentOrders: orders, stats };
    }
  }
};

Як реалізувати авторизацію та кешування в BFF?

BFF — природне місце для централізованої авторизації та кешування. JWT-токен перевіряється на рівні BFF, refresh token зберігається в httpOnly cookie (для веб-клієнта), а кеш у Redis прискорює відповіді для рідко змінюваних даних.

// authorization middleware
router.post('/auth/refresh', async (req, res) => {
  const refreshToken = req.cookies.refresh_token;
  if (!refreshToken) return res.status(401).json({ error: 'No token' });
  const tokens = await authService.refreshTokens(refreshToken);
  res.cookie('refresh_token', tokens.refreshToken, {
    httpOnly: true, secure: true, sameSite: 'strict',
    maxAge: 30 * 24 * 60 * 60 * 1000
  });
  res.json({ accessToken: tokens.accessToken });
});

// caching with Redis
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

async function getCachedOrFetch<T>(key: string, ttl: number, fetcher: () => Promise<T>): Promise<T> {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);
  const data = await fetcher();
  await redis.setex(key, ttl, JSON.stringify(data));
  return data;
}

Вибір між GraphQL і REST для BFF

Якщо клієнт — React-застосунок з Apollo Client, BFF може експортувати GraphQL-схему. Це дає клієнту можливість запитувати саме ті поля, які потрібні, без дублювання ендпоінтів. GraphQL BFF особливо зручний, коли вимоги до даних часто змінюються: клієнт сам контролює вибірку. Однак для простих мобільних застосунків з фіксованими екранами REST BFF часто виявляється ефективнішим через меншу складність.

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

• Аудит поточної архітектури та виявлення частих round trips.
• Проектування BFF-шару для кожного клієнта (REST або GraphQL).
• Розробка API з агрегацією даних та трансформацією.
• Впровадження авторизації (JWT, session-based).
• Кешування з Redis або in-memory.
• Обробка помилок і partial failures (Promise.allSettled).
• Документація (OpenAPI або GraphQL SDL).
• Тестування та навантажувальне тестування.
• Деплой (Docker, Nginx, Vercel, AWS Lambda).

Терміни реалізації

Процес роботи

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

Типові помилки при впровадженні BFF

• Дублювання логіки — кожен BFF дублює трансформації. Рішення: винести спільні функції в shared library.
• Монолітний BFF — один BFF для всіх клієнтів призводить до тих самих проблем, що й єдиний API. Кожен клієнт — окремий BFF.
• Ігнорування partial failures — якщо один сервіс не відповідає, BFF не повинен падати. Використовуйте Promise.allSettled.
• Відсутність кешування — без кешу кожен запит долітає до сервісів, збільшуючи навантаження та час відповіді.

Чому BFF перевершує єдиний API?

Без BFF клієнт змушений самостійно агрегувати дані, що веде до надлишкових запитів і ускладнення клієнтської логіки. BFF бере на себе оркестрацію: один запит від клієнта → паралельне опитування мікросервісів → агрегація → трансформація → відповідь. Це прискорює завантаження, знижує трафік і спрощує підтримку.

Наш досвід

Ми впровадили BFF для великого e-commerce проєкту. Результати:

Досвід наших інженерів — 8+ років у мікросервісній архітектурі. Замовте розробку BFF під ключ і отримайте гарантію на час відповіді та відмовостійкість. Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 1–2 дні. Замовте розробку BFF і отримайте оптимізацію під вашого клієнта.

Послуги бекенд-розробки: 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% без втрати продуктивності.