Паттерн Backend for Frontend (BFF) предполагает создание отдельных бэкендов для разных типов клиентов: веб, мобильных приложений, сторонних интеграций. Каждый BFF адаптирует API под нужды конкретного интерфейса, скрывая сложность внутренней архитектуры и агрегацию данных.
Это позволяет уменьшить логику на стороне клиента, сократить количество запросов, оптимизировать трафик и формат данных. BFF берет на себя трансформацию, кеширование, агрегацию и оркестрацию вызовов к микросервисам или монолиту, улучшая отзывчивость и пользовательский опыт.
Паттерн особенно полезен в системах с разнородными клиентами и активным развитием интерфейсов. Он позволяет эволюционировать фронтенд независимо от внутренних сервисов, а также снижает связность между UI и архитектурой бэкенда.
BFF появился как развитие идеи API Gateway, но с более тонкой настройкой под конкретный пользовательский интерфейс. Если API Gateway чаще является общей точкой входа и решает кросс-функциональные задачи (безопасность, маршрутизация, rate limiting), то BFF отвечает за адаптацию бизнес-данных и сценариев конкретного клиента. Фактически, у мобильного приложения, веб-клиента и внешнего партнера могут быть разные BFF, даже если внизу лежат одни и те же микросервисы.
Архитектор применяет BFF, когда видит, что фронтендам приходится решать слишком много «склейки»: собирать данные из разных API, трансформировать форматы, делать последовательности вызовов, бороться с сетевыми задержками. Это приводит к раздутой логике на клиенте, сложному коду и трудностям с повторным использованием. Перенося эту работу в BFF, архитектор концентрирует логику агрегации и адаптации в одном месте, где её легче тестировать, масштабировать и контролировать.
BFF может выполнять несколько важных функций:
-
оркестрация вызовов к нескольким микросервисам и объединение ответов в один;
-
преобразование доменной модели во «фронтенд-дто», удобные для конкретного экрана или сценария;
-
кэширование данных, чувствительных к производительности (например, справочники, профили, настройки);
-
управление версиями API для клиента, позволяя поддерживать разные версии интерфейса параллельно;
-
внедрение специфичной логики, связанной только с этим типом клиентов (например, мобильные ограничения по трафику).
Важно, что BFF не должен превращаться в «второй бэкенд» с собственными бизнес-правилами. Его роль — адаптация и координация, а не реализация ядра бизнес-логики. Это требует дисциплины: основные бизнес-правила остаются в доменных сервисах и микросервисах, а BFF лишь подстраивает данные под форму и сценарий использования.
В архитектуре BFF часто строится поверх API Gateway: внешний мир обращается в Gateway, который маршрутизирует запросы в соответствующий BFF, а тот уже работает с внутренними сервисами. В других случаях BFF сам выполняет роль точки входа для конкретного клиента. В обоих вариантах BFF помогает изолировать жизненный цикл фронтенда от внутренних изменений в архитектуре.
Паттерн особенно полезен в реальных продуктах, где есть мобильные приложения, SPA, партнерские кабинеты, третьи стороны и интеграции. У каждого типа клиента свои запросы по объему данных, частоте, формату и сценариям работы. BFF позволяет оптимизировать каждый канал, не ломая общий бэкенд.
На рынке труда BFF часто фигурирует в вакансиях архитектора и ведущего разработчика, особенно в компаниях с развитым продуктовым фронтендом. Ожидается, что архитектор понимает, когда нужен BFF, где его границы, как его не превратить в хаотичный слой с дублирующейся логикой и как связать его с микросервисной и событийной архитектурой.
BFF в итоге делает систему более гибкой, клиентские интерфейсы — более быстрыми и простыми, а архитектуру — более управляемой. Это паттерн, который живет на стыке фронтенда и бэкенда и требует от архитектора понимания обеих сторон.