Слой данных во фронтенде становится архитектурной темой сразу, как только экран перестаёт читать один API-адрес и начинает собирать пользовательский опыт из нескольких сервисов с разной скоростью ответа. В этот момент выбор между REST, GraphQL, BFF и загрузчиками маршрутов напрямую влияет на UX.
Глава ценна тем, что показывает поток данных как архитектуру, а не как набор сетевых вызовов. Здесь важно не только чем загружать данные, но и где выполнять агрегацию, кто отвечает за повторные попытки, как показывать устаревшие или частичные данные и каким остаётся контракт между интерфейсом и серверной стороной.
Для архитектурного ревью это полезный материал: он помогает обсуждать клиентские данные через границы ответственности, оркестрацию и обработку отказов, а не сводить всё к выбору протокола или библиотеки запросов.
Практическая польза главы
Практика проектирования
Разделяйте маршруты по способу загрузки данных: где достаточно REST, где нужен GraphQL, а где лучше собрать модель экрана в BFF.
Качество решений
Оценивайте слой данных по предсказуемости контрактов, обработке частичных сбоев, повторным попыткам, кэшу и цене агрегации.
Аргументация на интервью
Стройте ответ как цепочку: класс экрана, источники данных, место агрегации, стратегия ошибок, кэш и владение контрактом.
Формулировка компромиссов
Фиксируйте цену выбора: простота клиента, гибкость запросов, контроль серверного фасада, сложность эксплуатации и скорость изменения API.
Контекст
REST, gRPC и GraphQL
Выбор транспорта полезен только как часть большего разговора о контрактах для интерфейса, повторных попытках и агрегации данных.
определяет, насколько экран остаётся предсказуемым, когда ему приходится собирать ответ из нескольких серверных сервисов. Если интерфейс работает с и должен быстро отдавать , нужен явный архитектурный слой между экраном и деталями транспорта.
В зрелом фронтенд-приложении поток данных обсуждают не только через способ сетевого вызова. Важны , оркестрация, , и понятная зона ответственности.
Карта слоя данных во фронтенде
Один экран может читать REST-адреса напрямую, идти через GraphQL, получать готовую модель из BFF или сочетать несколько способов. Переключайте режимы, чтобы увидеть, где собираются данные и где лучше держать контракт.
BFF как серверный фасад под интерфейс
BFF собирает данные на серверной стороне и отдаёт экрану готовую модель представления.
Потребитель
Экран
Интерфейсу нужен компактный ответ без знания внутренней структуры сервисов.
Фасад
BFF
Слой учитывает аутентификацию, локализацию, права доступа и продуктовые сценарии.
Источники
Серверные сервисы
Внутренние домены могут оставаться независимыми и не подстраиваться напрямую под UI.
Итог
Модель экрана
Экран получает готовую форму данных, а сложность агрегации остаётся на сервере.
Когда выбирать
Когда выбирать
- Серверная сторона фрагментирована.
- Нужно скрыть внутренние DTO и собрать модель под экран.
- Важны контроль контракта, безопасность и единая обработка ошибок.
Базовые модели интеграции
REST + загрузчики маршрутов
Простой вариант для предсказуемых экранов и явных границ. Хорошо работает, когда экрану нужно небольшое число запросов, а контракт меняется спокойно и без частых разрывов совместимости.
GraphQL
Удобен, когда интерфейс собирает данные из нескольких доменов и часто меняет . Обратная сторона подхода: , сложность и защита от слишком дорогих запросов.
Бэкенд для фронтенда (BFF)
Такой слой нужен, когда серверная сторона слишком фрагментирована или когда интерфейс должен получать компактную с учётом аутентификации, локализации и продуктовой .
Гибридный подход
Один продукт часто сочетает несколько вариантов: для критичных пользовательских сценариев, GraphQL для исследовательских экранов с гибкими запросами и REST для стабильных операционных экранов.
Связано
Customer-Friendly API
Хороший слой данных во фронтенде почти всегда опирается на форму API, удобную продукту, а не только сервисной инфраструктуре.
Правила устойчивого потока данных
Частичный сбой нужно проектировать как часть UX
Если один виджет на аналитическом экране недоступен, остальная страница не обязана падать. должен различать , и .
Политика повторных попыток не живёт только в транспорте
Повтор запроса зависит от намерения пользователя, идемпотентности, стоимости загрузки и того, можно ли безопасно показать вместо агрессивной повторной загрузки.
Модель представления полезнее сырых сервисных контрактов
Интерфейс выигрывает, когда получает , близкую к экрану. Иначе оркестрация расползается по хукам, селекторам и дереву компонентов.
Контракты данных нужно развивать как публичный API
BFF, схема GraphQL и должны развиваться с понятной политикой вывода из эксплуатации. Иначе миграция экранов начинает блокировать всех команд.
Вопросы перед выбором BFF или GraphQL
- Сколько серверных доменов должен собрать один экран и где выгоднее делать .
- Нужна ли интерфейсу стабильная или отдельные уже достаточно близки к экрану.
- Насколько критичны , , и .
- Кто владеет : , продуктовая команда или серверная команда с .
Главный антипаттерн
Связанные главы
- Удалённые вызовы API: REST, gRPC и GraphQL - даёт сравнение транспортной модели и контрактов, поверх которого проще выбрать стратегию интеграции для интерфейса.
- Customer-Friendly API - помогает понять, почему должна быть удобна потребителю, а не только внутренним сервисам.
- Архитектура фронтенд-приложения: оболочка, функциональные модули и общее ядро - показывает, где именно проходит через и зоны владения модулем.
- Состояние и кэш во фронтенд-приложении - продолжает тему на уровне кэша запросов, и .
- Наблюдаемость, фича-флаги и безопасные релизы во фронтенде - добавляет диагностику сбоев данных, и метрики пользовательского опыта на клиентской стороне.
- Learning GraphQL - расширяет GraphQL-ветку отдельным источником по проектированию схемы и модели запросов.