Data layer во фронтенде становится источником архитектурной боли сразу, как только экран перестает читать один endpoint и начинает собирать опыт пользователя из нескольких сервисов, partial failures и разных скоростей ответа. В этот момент выбор между REST, GraphQL, BFF и route-level loaders начинает напрямую влиять на UX.
Глава ценна тем, что показывает data flow как архитектуру, а не как набор fetch-вызовов. Здесь важно не только чем грузить данные, но и где происходит aggregation, кто владеет retries, как обрабатываются stale/partial states и каким остается контракт между UI и backend.
Для design review это полезный материал, чтобы обсуждать клиентские данные языком boundary, orchestration и failure handling, а не сводить все к выбору transport-протокола или библиотеки запросов.
Практическая польза главы
Практика проектирования
Переводите знания о контрактах между UI и backend, orchestration и устойчивом data flow в конкретные решения по composition, владению (ownership) и runtime-поведению клиентской системы.
Качество решений
Оценивайте архитектуру по измеримым эффектам: скорость delivery, стабильность UI, наблюдаемость, цена изменений и эксплуатационные риски.
Аргументация на интервью
Стройте ответ как цепочку problem -> constraints -> architecture -> компромиссы (trade-offs) -> migration path, с явной аргументацией frontend-выбора.
Формулировка компромиссов
Фиксируйте компромиссы вокруг контрактах между UI и backend, orchestration и устойчивом data flow: масштаб команды, технический долг, performance budget и долгосрочная поддержка.
Контекст
REST, gRPC и GraphQL
Выбор транспорта полезен только как часть большего разговора о UI-facing contracts, retries и aggregation.
Data layer определяет, насколько экран вообще способен быть предсказуемым при сложном backend landscape. Когда UI разговаривает с несколькими сервисами, работает с partial failures и должен быстро отдавать view model, нужен явный архитектурный слой между экраном и transport details.
В зрелом frontend data flow обсуждают не только через слово fetch, а через contracts, orchestration, retries, stale states и ownership.
Базовые integration-модели
REST + route loaders
Прямолинейный вариант для предсказуемых экранов и явных boundaries. Хорошо работает, когда экрану нужно ограниченное число запросов и контракт эволюционирует стабильно.
GraphQL
Удобен, когда UI собирает данные из нескольких доменов и часто меняет shape ответа. Цена - schema governance, client cache complexity и защита от слишком тяжелых запросов.
BFF / UI orchestration layer
Нужен, когда backend landscape слишком фрагментирован или когда UI должен получать компактный view model с учетом auth, localization и product-specific aggregation.
Hybrid approach
Один продукт часто использует несколько modes одновременно: BFF для критичных flows, GraphQL для exploration-heavy surfaces и REST для stable operational screens.
Связано
Customer-Friendly API
Хороший frontend data layer почти всегда опирается на API shape, который удобен для продукта, а не только для сервисной инфраструктуры.
Правила устойчивого data flow
Partial failure должен проектироваться как часть UX
Если один widget в dashboard недоступен, остальной экран не обязан рушиться. Data layer должен уметь различать hard failure, stale fallback и incomplete response.
Retry policy принадлежит не только transport layer
Повтор запроса зависит от user intent, идемпотентности, стоимости загрузки и того, можно ли безопасно показать stale data вместо агрессивного refetch.
View model полезнее raw service contracts
Frontend выигрывает, когда получает API shape, близкий к экрану. Иначе orchestration размазывается по hooks, selectors и component trees.
Data contracts нужно версионировать как public API
BFF, GraphQL schema и typed clients должны эволюционировать с deprecation policy, иначе миграция экранов блокирует release cadence всех команд.
Вопросы перед выбором BFF или GraphQL
- Сколько backend-доменов должен собрать один экран и где выгоднее делать aggregation.
- Нужен ли UI стабильный view model или отдельные сервисные DTO уже достаточно близки к экрану.
- Насколько критичны partial response, cancellation, optimistic update и background refresh.
- Кто владеет schema evolution: frontend-platform, product team или backend team с UI-facing контрактом.
Главный антипаттерн
Связанные главы
- Удалённые вызовы API: REST, gRPC и GraphQL - даёт сравнение транспортной модели и контрактов, поверх которого можно выбрать UI-facing integration strategy.
- Customer-Friendly API - помогает понять, почему API shape должен быть удобен для потребителя, а не только для внутренних сервисов.
- Архитектура frontend-приложения: app shell, feature modules и shared kernel - показывает, где именно data layer проходит через feature boundaries и module ownership.
- Состояние и кэш во frontend-приложении - продолжает тему на уровне query cache, source of truth и invalidation.
- Observability, feature flags и безопасные релизы во frontend - добавляет диагностику data failures, rollback и UX health на клиентской стороне.
- Learning GraphQL - расширяет GraphQL-ветку отдельным источником по schema design и query model.