Источник
Customer-friendly API
Конспект доклада о клиент-ориентированных API.
Эта статья родилась примерно в 2020 году, когда я объяснял backend-командам, что «100500 отдельных endpoint-ов» не делают API удобным. Чтобы собрать один экран, клиентам иногда приходилось дергать по 50 разных handlers, что ломало UX и замедляло развитие продукта.
Customer-friendly API — это фасад, который отдаёт клиенту готовый сценарный payload, а не заставляет его собирать данные из множества сервисов.
API удобно нам ≠ удобно клиентам
Взгляд backend-команды
- Есть набор endpoint-ов и сервисов.
- Клиенты просто ходят за данными.
- Композиция данных считается задачей фронта.
Взгляд клиента
- Один экран = несколько разных API.
- Нужно агрегировать и склеивать ответы.
- Бизнес-композиция оказывается на клиенте.
Почему мобильным особенно больно
Tight coupling
Приложение жёстко связано с форматом и количеством API.
Дублирование логики
Одинаковая агрегация данных реализуется отдельно для iOS и Android.
Непрофильная работа
Композиция данных на фронте отвлекает от UI/UX и клиентской логики.
Долгий цикл изменений
Любая правка в агрегации требует релиза приложения.
Решение: клиент-ориентированный фасад
Что делает фасад
- Один вызов вместо набора round-trip запросов.
- Контракт под конкретный экран или сценарий.
- Композиция данных переносится ближе к бэкенду.
- Эволюция API без обязательного релиза клиента.
Результат
Клиент получает готовые данные в одном запросе, а бэкенд остаётся местом, где живёт бизнес-композиция и эволюция контрактов.
Клиенты
Web / Mobile
Фасад
BFF / GraphQL
Сервисы
Микросервисы
Два подхода к фасаду
BFF (Backend for Frontend)
Серверный слой под конкретный клиент: агрегирует данные и скрывает сложность.
GraphQL
Клиент сам задаёт форму ответа в рамках схемы.
Матрица выбора
BFF
контрольGraphQL
гибкостьОценки относительные: показывают, где больше контроля и где больше свободы в управлении API.
Контроль vs свобода
BFF = контроль на сервере
- Контракт под конкретный UI.
- Проще контролировать производительность и кэш.
- Меньше свободы - меньше рисков.
GraphQL = свобода для клиента
- Клиент формирует запросы под экран.
- Гибко для сложных UI и экспериментирования.
- Нужны ограничения, мониторинг и governance.
Гибриды и практика
- GraphQL может быть фасадом над сервисами.
- BFF может использовать GraphQL для части данных.
- API Gateway закрывает кросс-сечения, а BFF - клиентскую специфику.
Мини-чеклисты
API неудобно клиенту
- Один экран = 5-15 запросов.
- Клиент склеивает ответы разных сервисов.
- Формат данных меняется только через релиз клиента.
- У разных клиентов копипаста агрегации.
- Растёт число костылей и адаптеров.
Когда подходит BFF
- Разные клиенты требуют разные payload-ы.
- Мобильные релизы дорогие и редкие.
- Микросервисы дают много downstream-вызовов.
- Нужно изолировать изменения и дать автономию UI-команде.
Когда полезен GraphQL
- Сложные UI и много вариантов представлений.
- Хочется self-documentation и типизации схемы.
- Есть готовность инвестировать в ограничения и контроль запросов.
Вывод и рекомендации
Если нужен базовый и контролируемый способ сделать API удобным для клиента, BFF чаще выигрывает: он концентрирует контракт, снижает число вызовов и упрощает эволюцию клиентов.