BDUI для гуманитариев. Как бэкенд управляет интерфейсом

Традиционно бэкенд отвечает за обработку данных и бизнес-логику, а фронтенд — за отображение этих данных пользователю. При использовании BDUI бэкенд берёт на себя больше ответственности, формируя структуру интерфейса и определяя, какие компоненты и в каком порядке отобразит фронт. Фронтенд, в свою очередь, становится скорее «агентом», отвечая только за отрисовку полученной от бэкенда информации.

В классической архитектуре фронт получает и распределяет запросы от клиента, а бэк обрабатывает их. Фронтенд получает от бэкенда описание структуры экрана вместе с данными и не определяет, как их отображать. Бэкенд управляет логикой и структурой пользовательского интерфейса приложения. Он предоставляет готовые «схемы» экранов, определяя, какие элементы, в каком порядке и с какими параметрами должны быть отрисованы.

В итоге разработчики и бизнес получают централизованное управление на стороне сервера, адаптивность к различным платформам и снижение нагрузки на клиентскую часть.

1. Приложение запрашивает у бэкенда данные для отображения определённого экрана.
2. Бэкенд возвращает не просто данные, а описание структуры экрана: какие компоненты интерфейса и в каком порядке нужно отобразить, какие данные в них поместить, какие действия они должны выполнять.
3. Фронтенд получает эту «схему» и отрисовывает интерфейс в соответствии с полученными инструкциями.

Подход BDUI может внедряться в приложение на разных уровнях. Его можно использовать для управления отдельными компонентами интерфейса — например, формами — или же полностью перенести всю логику управления интерфейсом на бэкенд.

Рассмотрим на примере обычного приложения интернет-магазина, как работает BDUI. Пользователь запускает приложение и переходит на страницу с каталогом товаров. Вот что происходит под капотом:

1. Запрос страницы. Приложение отправляет запрос на получение страницы каталога товаров по определённому URL (например, /catalog). Этот запрос уходит на специальный сервис на бэкенде, задача которого — собрать все компоненты интерфейса. Назовём его «сборщик».

2. Этот «сборщик» получает запрос страницы. Он знает, где взять информацию о том, как эту страницу нужно отобразить. Он обращается к системе управления шаблонами интерфейсов.

3. В системе управления шаблонами хранятся описания всех экранов и компонентов приложения. Для страницы каталога товаров система возвращает в «сборщик» список компонентов — схему, в которой определён порядок компонентов на странице. Например:

{"type": "banner", "data": {"image": "/images/banner.jpg", "link": "/акции"}},

{"type": "productList", "data": {"category": "Электроника", "sort": "по популярности"}},

{"type": "footer", "data": {"copyright": "@2025 Наш магазин"}}

В этом примере список компонентов говорит, что на странице должны быть отображены: баннер, список товаров и подвал. Каждый компонент имеет свой тип (type) и набор данных (data), необходимых для его отображения.

4. Агрегация данных. «Сборщик», получив список компонентов, начинает запрашивать данные для каждого компонента из соответствующих бэкенд-сервисов. Например, для productList он обращается к сервису каталога товаров, передавая параметры category и sort.

5. Формирование ответа. «Сборщик» собирает все полученные данные и формирует окончательный ответ и отправляет его в приложение. Этот ответ содержит не только данные, но и описание структуры страницы — тот самый список компонентов.

6. Отображение интерфейса. Приложение получает ответ от «сборщика» и, используя полученный список компонентов и данные, отрисовывает интерфейс страницы каталога товаров.

BDUI и серверная отрисовка (SSR) — два разных подхода к разработке веб-приложений, которые часто путают, хотя они решают разные задачи.

При серверной отрисовке (SSR) бэкенд формирует HTML-код страницы и отправляет его клиенту (браузеру). Браузер просто отображает полученный HTML, не выполняя никаких дополнительных запросов к серверу. SSR выполняет две основные задачи:

• Улучшает поисковую оптимизацию (SEO). Поисковые роботы любят страницы, сгенерированные на сервере.
• Ускоряет первую загрузку страницы. Пользователь сразу видит готовый контент, не дожидаясь, пока браузер загрузит и выполнит JavaScript.

• SSR — это как если бы вам прислали готовую фотографию (HTML-код), которую вы просто вешаете на стену (отображаете в браузере).
• BDUI — это как если бы вам прислали набор деталей LEGO и инструкцию (список компонентов), по которой вы собираете модель (интерфейс) сами.

BDUI позволяет вносить изменения без обновления приложения. SSR в основном используется для улучшения SEO и ускорения первой загрузки страницы. Эти подходы можно комбинировать.

BDUI позволяет быстро вносить изменения в интерфейс, не выпуская новую версию приложения. Изменить акционный баннер на главной странице приложения с BDUI можно за несколько минут.

Централизованное управление интерфейсом упрощает процесс разработки и тестирования. Фронтенд-разработчики не тратят время на логику построения каждого экрана — соответственно, снижаются затраты на оплату труда разработчиков. Кроме того, BDUI упрощает поддержку приложения, так как все изменения вносятся «в одном окне» — на бэкенде.

BDUI позволяет проводить A/B-тесты различных вариантов интерфейса и мгновенно внедрять изменения на всех платформах.

BDUI позволяет персонализировать интерфейс для каждого пользователя на основе его предпочтений, демографических данных и поведения.

Пользователи получают доступ к новым функциям и контенту сразу же после их публикации на бэкенде, даже не обновляясь.

Фронтенд- и бэкенд-команды могут работать независимо друг от друга, что ускоряет процесс разработки. Бэкенд-разработчики могут изменять логику интерфейса, не затрагивая код фронта. Это упрощает внесение изменений и снижает риск конфликтов между командами.

Тщательное планирование и архитектурный подход. BDUI требует хорошо продуманной архитектуры и чёткого разделения ответственности между фронтендом и бэкендом. Нужна гибкая и масштабируемая система управления шаблонами интерфейсов.

Сложность в построении схемы без ошибок. Отрисовка экранов и их функциональности в режиме реального времени может привести к сложностям в отладке и тестировании. Любая ошибка в схеме может привести к некорректному отображению интерфейса и даже к сбою.

Централизованное управление логикой приложения на сервере может увеличить риски безопасности. Если злоумышленник получит доступ к системе управления шаблонами интерфейсов, он сможет изменить интерфейс приложения и, например, подменить платежные данные или отобразить фишинговую страницу.

Бэк должен обрабатывать не только данные, но и логику отображения интерфейса — это дополнительные вычислительные ресурсы.

BDUI — узкоспециализированный подход. BDUI лучше всего подходит для управления отдельными компонентами интерфейса — формами, списками, карточками товаров — или для создания простых и унифицированных интерфейсов.

BDUI требует постоянной синхронизации между фронтенд- и бэкенд-командами, так как бэкенд определяет структуру интерфейса, а фронтенд её реализует. Без чёткой коммуникации изменения на стороне сервера (например, обновление схем компонентов или параметров) могут привести к ошибкам отображения, несовместимости версий или конфликтам в логике интерфейса. Например, если бэкенд добавит новый тип виджета, а фронтенд не будет готов его обрабатывать, это может вызвать сбои. Координация также нужна для согласования форматов данных, документации, тестирования изменений...

В Ozon используют BDUI для управления карточками товаров, баннерами, акциями и навигацией в приложении и на сайте.

Результаты: менеджеры продукта самостоятельно без разработчиков запускают разные инициативы — меняют контент, проводят A/B-тесты и персонализируют предложения.

В «Яндекс Маркете» разработали фреймворк, включающий в себя библиотеки по отрисовке интерфейсов для Android, iOS и веб в «Маркете», «Алисе», «Едадиле» и приложении для ТВ.

Результаты: выросли скорость работы приложения и скорость разработки.

В «Циан» внедрили BDUI на Python.

Результаты: реализовали 2 отдельных BDUI-языка, научили бэкенд-разработчиков основам вёрстки, изменили принцип мышления заинтересованных сторон и запустили новую форму подачи объявления.

В «Авито» в рамках перехода на BDUI разрабатывают кроссплатформенный фреймворк Beduin, основанный на спецификации, позволяющей описывать конфигурацию интерфейса в формате JSON.

Результаты: Beduin включает в себя универсальный движок, разработанный с помощью Kotlin Multiplatform, который отвечает за вычисление состояния приложения, а также нативные средства отрисовки для каждой платформы.