BFF расшифровывается как Backend for Frontend — это архитектурный паттерн, при котором для каждого типа клиентского приложения (веб, мобильное, Smart TV) создаётся отдельный серверный прослойка-сервис, адаптирующий данные именно под нужды этого клиента. Если в вашем проекте мобильное приложение вынуждено делать пять запросов к разным микросервисам, чтобы отрисовать один экран, а веб-версия получает в ответе килобайты лишних полей — это типичный симптом отсутствия BFF-слоя.

Паттерн приобрёл популярность вместе с распространением микросервисной архитектуры: чем больше в системе независимых сервисов, тем сложнее клиенту собирать из их ответов цельную картину. BFF решает эту задачу, забирая логику агрегации и трансформации данных на серверную сторону, ближе к источникам данных.

Как устроен паттерн Backend for Frontend

Классическая схема выглядит так: клиент обращается не к десятку микросервисов напрямую, а к своему выделенному BFF-сервису. Тот, в свою очередь, запрашивает нужные внутренние сервисы, объединяет ответы, отбрасывает лишнее и возвращает клиенту один компактный результат в удобном формате.

Ключевая идея — один BFF на один тип клиента. Веб-приложение и мобильное приложение имеют разные требования: мобильному клиенту важны минимальный трафик и малое число запросов (экономия батареи и работа на нестабильной сети), веб-клиенту — богатые данные для сложных интерфейсов. Общий универсальный API неизбежно становится компромиссом, который плохо обслуживает обе стороны.

  • 📱 Mobile BFF — отдаёт урезанные модели данных, агрегирует несколько вызовов в один, учитывает ограничения мобильных сетей.
  • 🖥️ Web BFF — формирует данные для SSR-рендеринга, управляет сессиями и cookies, кэширует тяжёлые ответы.
  • 📺 BFF для других клиентов — Smart TV, голосовые ассистенты, партнёрские интеграции со своими форматами.
💡

BFF — это не замена микросервисам, а тонкий адаптер между ними и конкретным клиентом: он не содержит бизнес-логики, а только агрегирует и форматирует данные.