Привет! Меня зовут Олег Иванов, я руководитель мобильной разработки в Московском кредитном банке. Сегодня поговорим о Server Driven UI вот по такому плану:
что это вообще за технология
из чего она состоит
рассмотрим наши подходы к ее реализации
Начнем с терминологии
SDUI (Server Driven UI) — это пользовательский интерфейс, управляемый сервером.
Что такое пользовательский интерфейс? Среда, с помощью которой пользователь взаимодействует с программным обеспечением через приложения. Обычно он состоит из множества экранных форм, которые и ведут пользователя по флоу до какого-то определенного результата.
Если абстрагироваться от назначения экранных форм, то схематично User Flow можно представить так:
Каждая экранная форма состоит из графических (UI) компонентов, как будто состоит из кирпичиков Лего ☺.
Откуда берутся графические (UI) компоненты?
Любой фронтенд-разработчик всегда получает макеты от наших дизайнеров для того, чтобы дальше реализовать ту или иную экранную форму.
Но дизайнеры тоже не из головы их берут и не придумывают просто так — у них есть готовый набор компонентов (базовые графические (UI) компоненты, цвета, шрифты и прочее), он же UI Kit:
UI-компонентная база — это тот ресурс, который станет основным слоем для SDUI, чтобы воплотить нашу идею в жизнь. В итоговом формате UI-компонентная база будет своеобразным фреймворком, в котором будут реализованы те или иные графические компоненты на нужной нам платформе (то есть на любой нужной нам ОС, на которой мы хотим видеть наше приложение).
SDUI директивы, как команды от сервера
Итак, мы рассмотрели UI-компонентную базу, которая нам необходима как отдельный этап (№2 на изображении выше) для того, чтобы реализовать SDUI.
Но нам нужны еще и директивы сервера (№1 на изображении выше) плюс некий механизм, который будет понимать, как по этим директивам работать.
Как нам сконструировать эту форму? Тут есть три кита:
Набор реализованных на нужной платформе компонентов в фреймворке UI-компонентной базы
Механизм (реализованных на нужной платформе), позволяющий нам конструировать по командам сервера ту или иную форму
И список команд (директив) от сервера с их описанием
Для передачи этих команд мы выбрали удобный формат JSON.
Вот как в нем выглядит описание UI-компонента (в нашей терминологии Widget) по SDUI:
Обратите внимание, здесь идет императивный подход. То есть мы описываем, какие свойства должны быть у того или иного графического компонента. И мы здесь не привязывается к конкретной реализации — ведь она может отличаться в зависимости от платформы. Поэтому мы здесь всего лишь описываем свойства — с сервера приходят команды, которые описывают свойства, что должно отобразиться: нужный текст, цвет и любое иное свойство, которое нам нужно, все они регламентируются с сервера.
У нас есть большая UI-компонентная база, и наш механизм конструктора экранной формы должен знать, какой именно UI-компонент нужно вытащить из этой базы.
Основные свойства UI-компонента - это ID (идентификатор) и Type (тип)
Мы используем горизонтальное разбиение экранной формы для определения Widgets:
Экранная форма так же, как и графический компонент, имеет под собой воплощение в JSON-формате:
Представление экранной формы в JSON-формате имеет достаточно большой объем, особенно для сложных экранных форм с большим набором Widgets. Все директивы идут с сервера. И если нам, например, нужно в процессе работы приложения обновить/изменить некие данные только в одном Widget, передавать снова все описание экранной формы (которое кроме этого одного Widget не изменилось) выглядит накладно, плюсом сервер должен еще уметь корректно встроить передачу измененных данных этого Widget в общее JSON представление всей формы. И этот «момент» мы оптимизировали.
Наша оптимизация получила название «заготовка экранной формы». Заготовка — это файл, который содержит json-описание всей экранной форма, но без конкретных данных (!). В итоге получился некий Шаблон экранной формы.
Сами данные, которые нужно отобразить в экранной форме мы передаем с сервера в «облегченном варианте» в связке с идентификатором (ID) нужного Widgets с сохранением иерархии JSON-описания из заготовки, как для экранной формы в целом, так и конкретного Widget с указанием только идентифицирующих и изменяющихся параметров.
Вот как это выглядит в структуре HTTP ответа от сервера (см. параметр redrawingPage):
Прямо сейчас мы готовим такие заготовки вручную, процесс не самый удобный, но зато и не такой уж долгий. Ведь каждый компонент уже описан, уже есть аналитика и JSON-воплощение его свойств. Так что делать такие заготовки несложно.
Для серверной реализации SDUI хорошо подходит паттерн backend for frontend.
У нас один сервер может обслуживать несколько фронт-приложений и не все они поддерживают SDUI. Поэтому нашей серверной реализации мы использовали BFF как прокси – он преобразует стандартный ответ от сервера в ответ формата директив SDUI.
Плюсы внедрения SDUI
Вспоминаем фронт-реализацию:
готовая и реализованная компонентная база (внесение изменений в которую не так уж и часто)
готовый механизм конструирования экранных форм (внесение изменений в который минимально)
Самое важное преимущество SDUI — душевный покой фронтенд-разработчика ☺. Он больше не спешит, не делает формы с нуля и заново, не верстает, не изобретает «велосипед», написания не качественного кода — все уже готово!
С применением технологии SDUI мы можем смело говорить о нативной кросс-платформенности. Ведь наша заготовка и мета-язык (директивы SDUI) могут приниматься на любой платформе (ОС iOS, ОС Android, Web, Windows-Native, ... ОС Аврора), вся верстка и бизнес-логика в них уже зашиты. Все, что требуется от новой платформы, — это написать компонентную базу и общий механизм конструирования форм.
Еще ощутимо сокращается время выпуска новых версий — ведь все директивы SDUI идут с сервера. Так зачем нам новые версии в магазинах распространения, если мы можем просто добавить на сервер новые директивы? Технология SDUI полностью не избавит нас от выпуска новых версий, например, иногда надо отредактировать какие-то механизмы или ввести новые компоненты, так что совсем от релизов не уйти.
Также мы получаем инструмент для противодействия санкциям, банки особенно сильно столкнулись с тем, что их приложения поудаляли из магазинов распространения. SDUI по сути срабатывает как та самая «серебряная пуля», которая оживляет заблокированные приложения.
Не только мы используем эту технологию — есть реализация от Яндекса и других больших компаний:
Если вы уже использовали SDUI у себя и хотите поделиться опытом — буду рад вашим комментариям.
P.S. Это была вводная статья про возможности и использование SDUI, в следующих материалах мы рассмотрим это предметнее.
