BFF расшифровывается как Backend for Frontend — «бэкенд для фронтенда». Это архитектурный паттерн, при котором между клиентским приложением (сайтом, мобильным приложением) и внутренними сервисами компании ставится отдельный промежуточный слой, заточенный под конкретный интерфейс. Вместо того чтобы мобильное приложение напрямую дёргало десяток микросервисов и самостоятельно склеивало ответы, оно делает один запрос к своему BFF — и получает готовые данные в нужном формате.
Термин стал популярным в середине 2010-х годов, когда компании начали массово переходить на микросервисную архитектуру. Выяснилось, что «один общий API на всех» плохо работает: веб-версии нужны одни данные, мобильному приложению — другие, а умным часам — вообще минимальный набор. BFF решает эту проблему, позволяя каждому типу клиента иметь собственный «персональный» бэкенд.
Зачем нужен BFF: какую проблему он решает
Представьте интернет-магазин с микросервисной архитектурой: отдельные сервисы для каталога, цен, остатков, отзывов, доставки и пользователей. Чтобы отрисовать карточку товара, мобильному приложению пришлось бы сделать шесть-семь запросов к разным сервисам, дождаться всех ответов и собрать их воедино. На медленном мобильном интернете это превращается в заметные задержки и лишний расход трафика.
BFF забирает эту работу на себя. Клиент отправляет один запрос, а промежуточный слой сам обращается к нужным микросервисам, агрегирует данные, отбрасывает лишнее и возвращает компактный ответ, готовый к отображению. Сетевая логика уходит с устройства пользователя в контролируемую серверную среду, где связность между сервисами быстрая и предсказуемая.
💡BFF убирает с клиента логику агрегации данных: один запрос вместо множества, ответ в формате «как нужно именно этому экрану».