Привет, меня зовут Михаил Шевченко. В Авито я проектирую и разрабатываю backend low-code-платформы Bricks. Мой профессиональный путь — это разнообразные роли, от разработчика до архитектора. Я fullstack, обладающий навыками как во фронтенде, так и в бэкенде, а также есть у меня опыт создания мобильных приложений на React Native. В этой статье рассказываю о том, почему в Авито было принято решение развивать собственные low-code-решения и Backend-Driven UI, объясняю их устройство и делюсь достигнутыми результатами.
Что внутри статьи:
Какую проблему мы решаем?
Представим, что мы получили обратную связь от пользователей: цена в объявлении визуально сливается с заголовком. Перед нами стоит задача: поменять местами цену и заголовок, а для цены создать заметный фон. Задача требует реализации на всех платформах, где представлен Авито: Web, Android и iOS.
Как такие задачи решаются в стандартном флоу
Перед нами три платформы. Соответственно, необходимо добавить в бэклог три задачи, внести изменения в кодовую базу каждого проекта и пройти три полных релизных цикла со всеми этапами — от создания pull request и проведения code review до слияния с мастер-веткой.
В чем проблемы? Их несколько:
даже для решения самых тривиальных задач требуется привлечение квалифицированных кадров;
команда может быть загружена более приоритетными фичами;
изменения до каждой платформы доедут в разное время.
Различные платформы обновляются по-разному: для веба, например, достаточно обновить статику на сервере. А вот для мобильных приложений нужно собрать новую версию, выложить в магазин и дождаться, когда пользователи её скачают. Это отрицательно сказывается на Time to market (TTM) фичей и усложняет проверку гипотез.
Что еще можно сделать?
Вариант первый – можно сделать все на вебе.
Мы знаем, что веб обновляется быстрее всего. В мобильном приложении можно поднять специальную компоненту WebView и в ней запустить веб-контент – фактически это браузер внутри мобильного приложения.
Плюсы использования WebView:
все синхронно: не нужно ждать никаких обновлений со стороны пользователя;
кроссплатформенно: одна реализация будет работать на всех платформах;
TTM (скорость выхода фич от этапа идеи до этапа выхода в прод) сокращается, становится понятным и прогнозируемым.
Казалось бы, что еще нужно? Мобильная разработка сложнее, нужно переезжать на веб. Однако и у этого подхода есть минусы:
UI на вебе нельзя сделать полностью нативным;
проблемы с навигацией, особенно если часть приложения сделана на нативных технологиях, а часть — на WebView;
нет прямого доступа к API операционной системы. Мобильная ОС не знает, что за контент мы запускаем в WebView и не может ему давать те же привилегии, что и мобильному приложению. Ограничение можно обойти, но стабильности работе приложения это не добавит;
нельзя гибко сочетать разные технологии. Если мы используем WebView, то внутри него невозможно задействовать нативные компоненты, хотя такая необходимость может возникать.
Вариант второй — кроссплатформенные решения.
Можно посмотреть в сторону React Native от Facebook (принадлежит Meta, признанной экстремистской в РФ) и Flutter от Google. Эти решения в большей степени заточены под кроссплатформенность, что не покрывает всех кейсов, которые мы хотим решить. Про Flutter и React Native можно вообще написать отдельную статью со всеми плюсами, минусами и особенностями использования.
Какой путь выбрали мы в Авито?
Мы выбрали подход Backend-Driven UI (BDUI). Это концепция, основанная на разработке спецификации, позволяющей описывать конфигурацию пользовательского интерфейса в формате JSON. Для мобильного приложения создается движок, который получает конфигурацию от бэкенда и рендерит интерфейс с помощью нативных компонентов.
Beduin
Мы разрабатываем кроссплатформенный фреймворк Beduin.
Архитектура
Beduin включает в себя универсальный движок, разработанный с помощью Kotlin Multiplatform, который отвечает за вычисление состояния приложения, а также нативные рендеры для каждой платформы, созданные с использованием соответствующих технологий и библиотек.
Движок вычисляет состояние и передает его рендеру, который отрисовывает интерфейс на основе полученных данных. Затем рендер обменивается сообщениями с движком, после чего состояние пересчитывается и UI обновляется.
Как выглядит общая механика разработки UI и доставки до пользователя?
С одной стороны, фронтенд- или мобильный разработчик описывает UI, а затем передает конфигурацию бэкенд-разработчику, который интегрирует её в код бэкенд-сервиса.
С другой стороны, клиентское приложение запрашивает у бэкенда beduin-сценарий, который содержит конфигурацию интерфейса.
Бэкенд
Бэкенд не генерирует Beduin JSON «на лету». Благодаря поддержке реактивного обновления данных и декларативному подходу мы можем описать пользовательский интерфейс (UI) во всех его состояниях сразу.
Задачей бэкенда становится сбор динамических данных, представляющих собой начальное состояние приложения, и обогащение этими данными сценария. После этого сценарий отправляется обратно клиентскому приложению. Полученный JSON обрабатывается движком Beduin, предоставляя пользователю доступ к интерфейсу.
Beduin — это мощная технология, позволяющая фактически создавать UI на основе принципов SPA (Single Page Application). Мы можем собрать начальное состояние приложения и его вёрстку на сервере, а затем передать их клиентскому приложению. После этого, чтобы взаимодействовать с пользователем, нам не нужно обращаться к серверу за обновлениями вёрстки — все изменения происходят внутри клиентского приложения. К серверу мы обращаемся только для обновления данных.
Beduin в продакшн
Пример с несколькими экранами, с которыми вы можете взаимодействовать, используя Авито. Они реализованы с помощью Beduin.
Для внесения изменений достаточно обновить конфигурацию на бэкенде — UI автоматически изменится без необходимости загрузки новой версии мобильного приложения.
Итоги
Какие плюсы от внедрения BDUI? Можно выделить следующие:
не нужно ждать, пока пользователи обновят приложение;
кроссплатформенность: один сценарий работает на всех платформах;
сценарии способны реализовывать команды, в которых может не хватать ресурсов нативной разработки;
TTM сокращается, становится понятным, появляется возможность гибко проверять гипотезы.
Давайте еще раз посмотрим на общую схему:
Может возникнуть закономерный вопрос: зачем нам каждый раз релизить бэкенд при изменении UI, если у нас нет необходимости генерировать JSON «на лету», а только собирать динамические данные? Не проще ли было бы прикрутить API, создать админку и управлять сценариями Beduin через неё?
Однако стоит учитывать, что Авито — это большой и сложный технологический продукт. За разные части UI могут отвечать разные микросервисы и создание отдельной админки для каждого из них приведет к значительным накладным расходам.
Bricks
Именно поэтому мы решили создать платформенное решение, которое позволило бы интегрироваться различным частям Авито. Помимо оптимизации использования BDUI, перед нами стояла задача создания инструмента, которым могли бы пользоваться не только программисты, но и контент-менеджеры. Это позволило бы эффективно решать задачи, такие как быстрая проверка гипотез и кастомизация страниц под разные категории (недвижимость, работа, авто и другие). Такой подход также способствовал бы более эффективному использованию ресурсов команд, позволяя, например, контент-менеджерам участвовать в проверке гипотез и настройке страниц для различных категорий.
Это платформа для управления разметкой пользовательских интерфейсов с помощью независимых и переиспользуемых виджетов
В качестве клиентского рендер-движка используется Beduin
Из каких сущностей состоит Bricks?
Основной агрегирующей сущностью является шаблон. Он служит начальной точкой для определения правил описания интерфейса — будь то экран целиком или его отдельная часть.
Шаблоны содержат макеты. Каждый макет включает набор виджетов, их параметры и правила взаимодействия между ними. При этом каждая версия макета сохраняется вместе со всеми настройками конфигурации.
Виджеты представляют собой базовые элементы управления интерфейсом. Они могут быть как простыми атомарными элементами из дизайн-системы, такими как кнопка, так и сложными частями интерфейса со своей внутренней логикой.
Как выглядит общая механика создания UI? С одной стороны, разработчики реализуют виджеты на Beduin и регистрируют их в Bricks. Таким образом, формируется каталог виджетов.
С другой стороны, у нас есть сотрудники, ответственные за управление интерфейсом (UI). Это могут быть как разработчики, так и специалисты без технического бэкграунда. Их задача — настраивать макеты и добавлять в них виджеты, благодаря чему в рамках шаблона создаются новые версии макетов.
Как происходит регистрация виджета в Bricks?
Сперва разработчику виджета необходимо составить и описать его метаинформацию, включая название, описание и другие релевантные детали.
Затем следует определить контракт — параметры виджета, которые будут управляться через Bricks. Мы следуем принципу строгой типизации, поэтому каждый параметр имеет четко определенный тип и признак опциональности.
А дальше прямо через UI вставляется JSON с beduin-сценарием, который отвечает за отрисовку этого виджета.
В итоге для простого виджета время от его создания до регистрации в Bricks, когда его можно будет использовать на макете, составляет около 20-30 минут.
Далее у пользователя есть возможность взять виджет из каталога, добавить его на макет, дать ему понятную метку.
На следующем этапе открывается возможность настройки параметров виджета. Визуальный конструктор, основываясь на контракте виджета, автоматически генерирует форму, учитывая типы и обязательность полей. Пользователь может задать параметры вручную либо привязать их к динамическим данным.
Для обогащения разметки динамическими данными Bricks предоставляет две механики:
«контракт шаблона». Он определяет параметры, которые сервис-потребитель должен передать в Bricks, чтобы получить Beduin-сценарий;
«источники данных». Она представляет собой абстракцию над микросервисами Авито. Источник можно подключить к макету: тогда Bricks перед передачей разметки сервису-потребителю обращается к этим микросервисам и получает все необходимые динамические данные.
При настройке параметра у пользователя всегда есть выбор: ввести значение вручную или настроить динамическую привязку данных.
Процесс публикации выглядит для пользователя максимально просто. Достаточно нажать кнопку «опубликовать» и отметить, что готовая версия теперь является основной. Через минуту клиентские приложения получат обновлённый интерфейс.
Возвращаясь к примеру про пользовательский фидбек: на связке Bricks + Beduin поменять местами название и цену, а также сделать голубой бэкграунд можно примерно за 10 минут:
Как разметка попадает к пользователю?
Платформа Bricks состоит из трех компонент. Все начинается с админ-панели, где пользователь нажимает кнопку «опубликовать».
Затем запрос поступает в компоненту Backend, ответственную за хранение каталогов виджетов, источников данных и контрактов всех сущностей. Бэкенд выполняет валидацию и направляет запрос дальше, в компоненту под названием Composition.
Composition — высоконагруженный микросервис, отвечающий за взаимодействие с сервисами-потребителями. На этапе публикации он анализирует конфигурацию макета, собирает единый законченный сценарий из виджетов (каждый из которых является отдельным beduin-сценарием) и сохраняет в свою БД.
С другой стороны, пользователь взаимодействует с клиентским приложением.
Клиентское приложение отправляет запрос в микросервис, ответственный за соответствующую часть UI. Микросервис собирает все нужные входные данные, согласно контракту шаблона, и отправляет запрос на получение разметки в сервис bricks-composition.
Composition определяет основную версию макета, проверяет наличие подключенных источников данных и необходимость обращения к другим микросервисам. Затем он дополняет сценарий собранными данными и возвращает готовую разметку сервису-потребителю, который передает эту разметку клиентскому приложению, обеспечивая пользователю доступ к интерфейсу.
Что еще можно делать в Bricks?
Простого создания виджетов недостаточно — важно уметь адаптировать разметку. Предположим, что нужно добавить секцию «онлайн-показ», но не для всех пользователей, а только для тех, кто соответствует определенным условиям: например, версии приложения, участию в A/B-тестировании или на основании данных, полученных от внешнего сервиса. Для решения подобных задач в Bricks реализована система зависимостей, которая позволяет гибко управлять отображением элементов интерфейса.
Кроме того, можно настроить интерактивное взаимодействие между пользователем и интерфейсом. Например, в разделе «онлайн-показ» можно добавить кнопку, которая позволит пользователю скрыть этот блок, если он ему не нужен.
Для реализации подобного взаимодействия также используются зависимости, которые можно подписать на события виджетов.
На этапе публикации Bricks-composition проверяет наличие зависимостей. Если зависимость не подписана на событие, она всегда будет вычисляться в момент запроса разметки и применяться к сценарию. Если зависимость привязана к событию виджета, то генерируется нужный beduin-обработчик на этапе публикации.
Что делать, если что-то пошло не так?
Bricks позволяет откатиться на любую версию макета и сделать её основной.
Конечные устройства пользователей начнут получать другую версию UI в течение одной минуты.
Что мы получили в результате внедрения этих технологий:
сотрудники без навыков программирования, например, контент-менеджеры, могут настраивать и менять пользовательский интерфейс;
высвобождение ресурсов разработчиков для решения сложных и комплексных задач;
возможность быстрой проверки гипотез;
радикальное сокращение Time to market для целого ряда задач.
Спасибо за уделённое статье время! На вопросы о Bricks, Beduin и нашем опыте готов ответить в комментариях.
Этот материал написан по мотивам моего выступления на конференции Avito All Day Long. Вот его запись:
А эта ссылка — для тех, кто хочет посмотреть выступление на YouTube.
Больше о наших мероприятиях, выступлениях и том, какие задачи решают инженеры Авито, — на нашем сайте и в телеграм-канале AvitoTech. А вот здесь — всегда свежие вакансии в нашу команду.
Yevvv
Спасибо за статью. Есть ли какой-то функционал приема данных от клиентов? Если да, то как реализовано сохранение динамических полей и взаимодействие с существующими сущностями? Например я создал две формы, в каждой форме часть полей - это существующие атрибуты пользователя, другая часть - индивидуальные для каждой формы новые поля. Как будут обрабатываться сабмиты данных форм?