BFF и API Gateway: два паттерна, которые решают разные проблемы — и их часто путают

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

Кому смотреть: разработчикам и архитекторам, проектирующим API для нескольких типов клиентов — мобильного приложения, веба, внешних партнёров — и чувствующим, что один общий backend начинает проигрывать в гибкости.

Из этого можно взять в работу: посмотрите на ваш API и спросите: сколько данных, которые возвращает один эндпоинт, реально используется мобильным клиентом? Если меньше половины — это сигнал, что клиент переплачивает за лишний трафик и обработку.

Когда использовать API Gateway: когда у вас много сервисов и нужна централизованная точка для cross-cutting concerns — auth, SSL termination, логирование, rate limiting. Gateway абстрагирует клиента от внутренней структуры системы: клиент вызывает один эндпоинт, не зная, что за ним стоят десять разных сервисов.

Когда добавлять BFF: когда разные типы клиентов имеют принципиально разные потребности в данных и форматах. Классический пример — Netflix: они переехали к BFF именно потому, что Smart TV, мобильный и веб требовали разных данных в разных форматах, и попытка обслужить всех одним API приводила к компромиссным решениям, неудобным для каждого.

Типичная ловушка: BFF превращается в “умный” backend с собственной бизнес-логикой. Это архитектурная ошибка — BFF должен агрегировать и трансформировать данные, но не содержать бизнес-правил. Бизнес-логика, дублированная в трёх BFF — это трёхкратный технический долг.

Связь с GraphQL: BFF и GraphQL решают похожую проблему (клиент берёт ровно те данные, которые нужны) разными способами. BFF — это отдельный сервис на стороне backend. GraphQL — протокол запросов, который клиент управляет самостоятельно. В некоторых архитектурах GraphQL заменяет BFF; в других BFF реализован через GraphQL-слой.