Backend for Frontend - окремий серверний шар під конкретний клієнт: веб-застосунок, мобільний застосунок, адмінка. Кожен BFF збирає дані з внутрішніх сервісів у формі, зручній саме своєму інтерфейсу.
веб-застосунок → BFF для вебу ↘
мобільний застосунок → BFF для мобільних → сервіси замовлень, користувачів, каталогу
партнерське API → публічне API ↗
Яку проблему розв'язує. Одне загальне API для всіх клієнтів поступово обростає компромісами:
- мобільному застосунку на повільній мережі потрібні компактні відповіді, а вебу - більше даних за раз;
- екран збирається з п'яти запитів до різних сервісів - на мобільній мережі це повільно;
- зміна, потрібна одному клієнту, ламає іншого;
- команда фронтенду чекає на команду API заради кожного нового поля.
Що робить BFF:
- агрегує: один запит від клієнта - кілька паралельних запитів до сервісів - одна відповідь під екран;
- адаптує формат: лише потрібні поля, зручна структура, локалізовані підписи;
- тримає автентифікацію браузера: BFF працює з сесійними cookie (
HttpOnly), а токени до внутрішніх сервісів не потрапляють у браузер. Це рекомендований підхід для SPA з OAuth; - належить команді фронтенду - вона змінює його у власному темпі.
Ви, можливо, вже маєте BFF:
- Next.js з серверними компонентами й Route Handlers - фактично BFF для React-застосунку;
- Laravel з Inertia - контролери готують props саме для сторінок Vue/React;
- GraphQL частково вирішує ту саму проблему іншим способом - клієнт сам вибирає поля.
Коли BFF виправданий:
- кілька клієнтів з суттєво різними потребами;
- мікросервісна архітектура, де клієнтові інакше довелося б знати про багато сервісів;
- окремі команди фронтенду, яким потрібна незалежність.
Коли зайвий: один клієнт і моноліт - сам моноліт уже є «бекендом для фронтенду».
Ризики: дублювання логіки між кількома BFF (спільне виносять у сервіси), і бізнес-правила, що непомітно переїжджають у BFF. BFF має лише збирати й адаптувати дані, а не вирішувати, наприклад, чи можна оформити замовлення.