Мобильное приложение открывает экран заказа и делает несколько запросов подряд. Веб-версия показывает ту же информацию иначе и нуждается в дополнительных деталях. Команда пытается обслуживать оба интерфейса одним универсальным API и постепенно добавляет туда условия «если мобильный», «если веб» и «если партнёр».
Backend for Frontend, или BFF, предлагает отдельный слой, который формирует данные и операции под потребности конкретного клиентского канала. Но это не приглашение копировать всю бизнес-логику для каждой платформы.
Сколько данных действительно нужно экрану
Для мобильного клиента важны размер ответа, число сетевых обращений и время загрузки. Веб-кабинету иногда нужны расширенные таблицы, фильтры и аналитика. Если один API возвращает слишком много или заставляет клиента собирать экран из множества вызовов, отдельный BFF может упростить работу.
Он агрегирует данные, адаптирует формы ответа и скрывает от интерфейса часть внутренней структуры системы. При этом основные правила — можно ли вернуть заказ, какая скидка допустима, кто имеет право менять статус — должны оставаться в соответствующих доменных сервисах.
Команда интерфейса получает скорость или новый узкий участок?
В удачной модели команда продукта владеет своим BFF и может менять представление для экрана, не ожидая общего релиза универсального API. В неудачной — появляется ещё одна команда-посредник, через которую приходится согласовывать каждое поле.
Поэтому польза зависит не только от схемы, но и от ownership: кто поддерживает BFF, кто отвечает за задержки, кто следит за безопасностью и совместимостью клиентов разных версий.
Почему BFF не заменяет API Gateway
API Gateway обычно концентрируется на общих задачах внешнего доступа: маршрутизации, проверках, лимитах. BFF ориентирован на конкретный интерфейс и его данные. Они могут сосуществовать, но не обязаны появляться вместе.
Не стоит прятать в BFF авторизацию только на уровне экрана. Внутренние сервисы должны проверять полномочия там, где выполняются важные бизнес-действия, а не полагаться на доброжелательность клиентского слоя.
Когда общий API всё-таки проще
Если веб и мобильное приложение используют почти одинаковые сценарии, а количество запросов и объём данных не создают проблем, отдельные BFF увеличат число компонентов, которые нужно тестировать и сопровождать.
Я бы сначала посмотрел на конкретные экраны: сколько запросов они делают, сколько ненужных данных получают и как часто команды блокируют друг друга при изменениях. Только затем решал бы, действительно ли нужен ещё один слой.
BFF полезен, когда помогает команде быстрее менять клиентский опыт, не распыляя одни и те же бизнес-правила по нескольким местам.