Разбираемся с BFF (Backend for Frontend) — слоем между интерфейсом и доменными сервисами, который берёт на себя агрегацию данных, кэширование и защиту от нестабильности внутренних систем.
О том, как BFF применяют в RWB, расскажут Александр Краснянский, Frontend Lead команды РКИ, и Сергей Корень, Backend Lead главной страницы и онбординга Портала Продавца.
⏹️Когда фронтенду действительно нужен свой BFF?
BFF становится нужен, когда поддержка логики на фронтенде или координация между несколькими командами обходится дороже, чем отдельный сервис.
Простой признак: чтобы отрисовать один экран, фронтенд делает пять запросов в разные сервисы. Логику агрегации и трансформации данных в этом случае переносят в BFF — и фронтенд начинает работать с одним API.
⏹️Где сейчас проходит граница между фронтендом и бэкендом?
Не между браузером и сервером, а между пользовательским опытом и бизнес-доменом.
Бэкенд отвечает за доменную логику и хранение данных, фронтенд — за сценарий и отображение. BFF — между ними: не содержит бизнес-логику, но берёт на себя композицию данных и адаптацию контрактов под конкретный интерфейс.
⏹️Как BFF ускоряет разработку продуктов?
Главное преимущество — не нужно согласовывать доработки сразу в нескольких бэкенд-командах.
Если новая страница требует данные из нескольких сервисов, BFF собирает контракт на своей стороне и отдаёт фронтенду единый API. Фронтенд и BFF-команда разрабатывают функциональность параллельно с доменными сервисами — это сокращает зависимости и ускоряет вывод фич на продакшен.
⏹️Как не допустить дублирования бизнес-логики в BFF?
Бизнес-логика остаётся в доменных сервисах. В BFF допускается только логика представления: агрегация, преобразование моделей, сценарии взаимодействия.
Помогают: чёткое разделение ответственности между слоями, контрактное проектирование API, общие библиотеки для типизации и автогенерация клиентов по OpenAPI и GraphQL-схемам.
⏹️Не увеличивает ли BFF задержки и риски для безопасности?
Задержки — как правило, нет: BFF выполняет параллельные запросы, агрегирует и кэширует ответы, поэтому пользователь получает один оптимизированный запрос вместо серии обращений.
С безопасностью BFF работает по принципу минимально необходимых привилегий: обращается к сервисам от имени конкретного пользователя, разграничивает доступ и не даёт внутренним сервисам быть напрямую доступными извне.
⏹️Самый интересный кейс с BFF
Главная страница Портала Продавца зависит от сервисов с разными SLA: один отвечает за 50 мс, другой — за 500, третий может периодически деградировать под нагрузкой.
BFF берёт на себя управление таймаутами, кэшированием и сценариями деградации — и отдаёт фронтенду стабильный контракт, даже когда часть сервисов работает нестабильно.
⏹️Как устроена команда, которая работает над BFF?
Чаще всего это кросс-функциональная продуктовая команда: фронтенд- и бэкенд-разработчики, QA-инженеры, DevOps/SRE-инженеры, аналитики и продуктовые менеджеры.
Хорошая практика — когда инженеры понимают обе стороны системы и вместе проектируют контракты. Цель — минимизировать межкомандные зависимости и повысить скорость поставки продукта.
⏹️Какие навыки нужны инженеру и что в этой работе нравится больше всего
Сильный инженер разбирается и во фронтенде, и в бэкенде: знает JavaScript/TypeScript/Go, умеет проектировать API и работать с микросервисной архитектурой. Но главное — системное мышление: видеть продукт целиком, а не только свой слой.
BFF находится на стыке фронтенда и бэкенда, поэтому влияет на весь пользовательский сценарий. Главный челлендж — не превратить BFF в ещё один монолитный бэкенд. Главный плюс — быстро адаптировать систему под продукт без изменений в доменных сервисах.