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

Backend Driven UI (BDUI, Backend-Driven Development, Server-Driven UI) — это подход к разработке интерфейсов, в котором бэкенд определяет не только данные, но и структуру, логику и контент интерфейса. Сегодня разработка и поддержание ПО по методу BDUI распространены широко, и на это есть причины. В материале выясняем, что это за зверь, какие задачи помогает решать и какие нюансы нужно учесть, если решили внедрить. Материал для нетехнических специалистов, поэтому если вы опытный разраб — поищите более хардкорные статьи по теме 🙂

Что такое Backend Driven UI (BDUI)

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

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

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

Бэкенд в этом случае — это такой архитектор, который создаёт чертёж дома (в нашем случае интерфейса), а фронтенд — строитель, который воплощает этот чертёж в жизнь. Архитектор решает, где будут стены, окна и двери. Строитель смотрит в план и строит.

Как это работает

1. Приложение запрашивает у бэкенда данные для отображения определённого экрана.

2. Бэкенд возвращает не просто данные, а описание структуры экрана: какие компоненты интерфейса и в каком порядке нужно отобразить, какие данные в них поместить, какие действия они должны выполнять.

3. Фронтенд получает эту «схему» и отрисовывает интерфейс в соответствии с полученными инструкциями.

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

Как это на практике

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

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

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

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

 ```json

     {

         "type": "banner",

         "data": {

             "image": "/images/banner.jpg",

             "link": "/акции"

         }

     },

     {

         "type": "productList",

         "data": {

             "category": "Электроника",

             "sort": "по популярности"

         }

     },

     {

         "type": "footer",

         "data": {

             "copyright": "@2025 Наш магазин"

         }

     }

     ```

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

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

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

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

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

Backend Driven UI vs Server-Side Rendering (SSR): в чём разница?

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

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

Улучшает SEO. Поисковые роботы любят страницы, сгенерированные на сервере.

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

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

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

Преимущества Backend Driven UI

🟣Быстрая разработка и развертывание

Ускорение Time to Market (TTM)

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

Сокращение расходов на разработку и поддержку

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

🟣 Гибкость и адаптивность

A/B-тестирование и быстрое внедрение изменений

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

Персонализация интерфейса под конкретного пользователя

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

🟣Улучшенный пользовательский опыт

Мгновенное обновление контента и функций

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

Независимость фронта и бэка

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

Недостатки Backend Driven UI

🟣 Сложность реализации

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

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

🟣Безопасность

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

🟣 Увеличение нагрузки на бэкенд

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

🟣 Ограниченность

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

🟣Повышенные требования к координации

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

Как большие компании используют BDUI

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

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

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

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

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

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

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

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