В начале один backend обычно обслуживает всё: сайт, мобильное приложение, иногда внутреннюю панель. Это удобно, пока всем клиентам нужны примерно одинаковые данные и одинаковый темп изменений.
Проблема появляется позже. Мобильному приложению нужно экономить трафик и количество запросов, вебу — собирать больше данных на большой экран, а внутреннему интерфейсу — совсем другой набор операций. Один универсальный API постепенно становится компромиссом для всех.
Какую проблему мы решаем
BFF — Backend for Frontend — добавляет отдельный серверный слой для конкретного клиентского интерфейса. Мобильное приложение обращается к своему BFF, веб — к своему. За ними могут оставаться те же внутренние сервисы.
BFF собирает данные, меняет их форму, объединяет несколько внутренних вызовов и отдаёт клиенту именно то, что ему нужно.
Что получает бизнес
Главная бизнес-выгода — каналы могут развиваться более независимо.
Если мобильная команда хочет изменить экран или запустить новую функцию, ей реже приходится ждать изменения общего API, которое затрагивает веб и другие потребители. Это сокращает координацию и может ускорять запуск продуктовых изменений.
Есть и второй эффект: клиентский канал можно оптимизировать под его реальные ограничения. Для мобильного приложения это может быть меньше сетевых вызовов, для веба — более богатые данные, для партнёрского интерфейса — стабильный отдельный контракт.
То есть BFF имеет смысл не потому, что «так современнее», а когда стоимость согласования между каналами уже становится заметной для бизнеса.
Что получает команда
Frontend-команда получает слой, который ближе к её продуктовым задачам. Она меньше зависит от универсального backend-контракта и может агрегировать внутренние сервисы под конкретный интерфейс.
Но BFF не должен превращаться в место, куда незаметно переезжает бизнес-логика. Иначе одинаковые правила начинают дублироваться в мобильном и веб-BFF и расходиться со временем.
Что получает клиент
Клиент получает интерфейс, который быстрее отвечает и лучше соответствует конкретному устройству или каналу.
Пользователь не видит BFF. Он замечает другое: экран загружается одним запросом вместо пяти, мобильное приложение меньше зависит от нестабильной сети, а новая функция появляется быстрее.
Чем мы за это платим
Цена — дополнительные сервисы, которые нужно разворачивать, тестировать, мониторить и поддерживать.
Появляется риск дублирования: два BFF могут реализовать похожую агрегацию по-разному. Ещё один риск — слишком сильная привязка backend-слоя к текущему интерфейсу, из-за чего каждое изменение UI начинает требовать серверного релиза.
Организационно нужно понимать, кто владеет BFF: frontend-команда, platform-команда или общий backend.
Когда BFF не нужен
Если клиентов мало, их потребности похожи, а общий API не тормозит развитие продукта, отдельные BFF просто увеличат количество кода.
Иногда достаточно нескольких удобных endpoint’ов или GraphQL-слоя без создания отдельного backend на каждый канал.
Что стоит спросить перед решением
- Насколько сильно отличаются потребности мобильного приложения, веба и других клиентов?
- Тормозит ли общий API независимое развитие этих каналов?
- Кто будет владеть каждым BFF?
- Как не допустить дублирования бизнес-логики?
- Не решаем ли мы проблему, которой пока нет?
В итоге
BFF — это способ признать, что разные клиентские каналы могут иметь разные потребности и разный темп изменений.
Для бизнеса его ценность появляется тогда, когда независимость каналов ускоряет продукт сильнее, чем дополнительный слой увеличивает стоимость разработки и эксплуатации.