Сейчас многие компании выбирают BDUI для реализации экранов или иногда целых приложений.
Идея подхода проста - бэкенд определяет как должен выглядеть экран приложения. Т.е. в приложение прилетает условный json, который описывает верстку экрана - какие элементы должны отображаться на экране и в какой последовательности. Более навороченные версии умеют строить схемы взаимодействия между экранами, описывать действия по клику на элементах и т.п.
✅Основной плюс - этот подход отлично работает с интерфейсами, которые могут часто меняться - вам не нужно делать перевыпуск приложения в маркете, изменения можно сделать буквально за пару часов, сильно сокращается time-to-market.
На моем опыте этот подход мы использовали аж в 2016 году, когда разрабатывали приложения для контроля работы мерчендайзеров. Кстати, однажды рассказывал, какие они фокусы вытворяли, чтобы обмануть наше приложение. Так вот, мы столкнулись с проблемой того что анкета мерчендайзера часто менялась и приходилось перевыпускать приложения, что занимало много времени. После применения BDUI подхода для анкеты, ее можно было легко настраивать на сервере и обновлять, не перевыпуская приложение. После этого использовал данный подход еще в нескольких компаниях, включая Яндекс.
Однако как и другие технологии, этот подход имеет свои недостатки:
❗️ Сложность реализации - требуютcя силы бэкенд и мобильных разработчиков. В зависимости от потребности к гибкости решения, трудозатраты могут сильно расти. Необходимо учитывать множество корнер кейсов и стратегии ошибок, когда с сервера прилетает кривая верстка. Нужно закладывать много времени на тестирование.
❗️ Сложность поддержки - скорее всего вы захотите делать доработки для своего BDUI и столкнетесь с вопросами как поддерживать приложения со старыми версиями BDUI, как дорабатывать его компоненты, как версионировать и релизить новые версии BDUI
❗️ Не подходит для тяжелых вьюх, либо там где важна скорость отрисовки. Основной минус подхода - в случае когда нужна скорость отображения пользователю, плавность и хороший пользовательский опыт, лучше не использовать этот подход, т.к. в нем больше накладных расходов на отрисовку, чем в случае классического подхода
❗️ Более хитрая схема взаимодействия с бэкендом - дополнительная нагрузка на сервер, большое количество дополнительных запросов. Кроме того вам понадобится продумать что показывать пользователю на стороне приложения, пока экран не загружен, нужно ли заранее делать подгрузку данных об экране, чтобы быстрее показать ее пользователю и т.п.
⚡️Подход backend-driven UI хорошо подходит для определенных кейсов, когда интерфейс пользователя часто меняется, позволяет существенно сократить time-to-market. Но имеет свои недостатки, в виде более сложной разработки и поддержки, меньшей скорости отрисовки и дополнительных накладных расходах и плохо подойдет для сложных интерфейсов. Выбор любого инструмента для работы должен быть хорошо продуман, BDUI здесь не исключение и за очевидными бонусами стоят не совсем очевидные минусы, учитывайте это при выборе подхода.
🔥 - или любая реакция, если этот пост был полезен