Настройка Server-Driven UI для мобильного приложения

Настройка Server-Driven UI для мобильного приложения

Server-Driven UI — архитектурный паттерн, при котором сервер отдаёт не только данные, но и описание того, как их отобразить. Мобильный клиент — универсальный рендерер, который по JSON-схеме строит экраны динамически. Airbnb применяет это в Ghost Platform, Airbnb Lottie и Epoxy. Mercado Libre — на большей части экранов приложения.

Почему это сложнее, чем кажется

На первый взгляд: «отдаём JSON с описанием экрана — клиент рендерит». На практике — это полноценный рантайм и UI-движок, который нужно спроектировать, версионировать, тестировать и поддерживать.

Версионирование схемы. Пользователи обновляют приложение медленно. Если сервер отдаёт "type": "new_component", а клиент версии 2.1 его не знает — экран упадёт или отобразится некорректно. Нужна стратегия: fallback компонент, минимально поддерживаемая версия, graceful degradation.

Типизация и валидация. Без строгой схемы (JSON Schema, Protobuf, kotlinx.serialization с sealed classes) сервер может отдать невалидный payload, и крэш будет на клиенте, а не там где ошибка. На iOS — Codable с DecodingStrategy.useDefaultValues, на Android — @SerialName + sealed class с @JsonClassDiscriminator.

Производительность парсинга. Сложный экран в JSON — 5–50 KB. На каждый скролл ленты это не пересчитывается, но cold render при первом открытии + кеширование схемы — отдельная инженерная задача.

Архитектура SDUI-системы

Серверная часть

Сервер хранит компонентное дерево для каждого экрана. Структура:

{
  "version": "1.0",
  "screen": {
    "type": "scroll_view",
    "children": [
      {
        "type": "hero_banner",
        "props": {
          "imageUrl": "https://cdn.example.com/banner.jpg",
          "title": "Летняя распродажа",
          "action": { "type": "navigate", "route": "/sale" }
        }
      },
      {
        "type": "product_grid",
        "props": {
          "columns": 2,
          "dataSource": { "endpoint": "/api/products/featured" }
        }
      }
    ]
  }
}

Компонентная система — реестр типов: hero_banner, product_grid, text_block, cta_button, carousel. Новый тип компонента добавляется на сервере и в клиент одновременно, деплоится через App Store/Play Store с новой версией приложения.

Клиентская часть (iOS — SwiftUI)

// Component Registry — реестр всех известных типов
enum ComponentType: String, Codable {
    case heroBanner = "hero_banner"
    case productGrid = "product_grid"
    case unknown
}

// Renderer — рекурсивный рендер дерева
@ViewBuilder
func renderComponent(_ component: SDUIComponent) -> some View {
    switch component.type {
    case .heroBanner:
        HeroBannerView(props: component.props)
    case .productGrid:
        ProductGridView(props: component.props)
    default:
        // Graceful fallback для неизвестных типов
        EmptyView()
    }
}

На Android — аналогично через Jetpack Compose с when (component.type). Flutter — switch по типу с фабричным методом для каждого widget.

Когда SDUI оправдан

• Частые изменения лейаута без релиза приложения (маркетинговые баннеры, промо-экраны, экраны онбординга)
• A/B тесты на уровне экранов: сервер отдаёт разные схемы разным сегментам пользователей
• Нескольких брендов на одном приложении: белый лейбл, где каждый клиент видит свой экран
• Мощная редакторская команда: CMS-интерфейс позволяет нетехническим сотрудникам менять экраны

Когда SDUI не нужен: приложение со стабильным UI, маленькая команда, нет бизнес-требования менять экраны без App Store релиза.

Реальный кейс

Ритейл-приложение, iOS + Android. Маркетинговая команда хотела менять главный экран (баннеры, категории, рекомендации) еженедельно — без ожидания 2–3 недель на App Store Review. SDUI внедрялся поэтапно: сначала только главный экран (Hero Banner + Category Grid), через три месяца — страницы категорий и карточки товаров. Backend — CMS на Laravel с визуальным редактором схемы. Клиент — iOS SwiftUI, Android Compose. Через 4 месяца маркетинг самостоятельно публикует новые экраны без участия мобильных разработчиков.

Инфраструктура и CDN

Схемы экранов кешируются на CDN (CloudFront, Fastly) с Cache-Control: max-age=300. Инвалидация через stale-while-revalidate — пользователь сразу видит кешированную версию, фоном грузится свежая. Для критических изменений — Surrogate-Key для точечной инвалидации конкретного экрана.

Сроки: базовая SDUI-система (3–5 типов компонентов, один экран) — 4–6 недель. Полноценная платформа с CMS-редактором, A/B тестингом, версионированием схем — 12–20 недель.