#bdui — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #bdui, aggregated by home.social.
-
Как мы переводили страницу объявления на Beduin в мобильной версии Авито
Всем привет! Меня зовут Егор Савинцев , я Frontend Platform Engineer в Авито . Сейчас я работаю в команде архитектуры, а до этого в команде Phobos в рамках Платформизации переводил страницу объявления на Beduin — разрабатывал клиентскую архитектуру и переписывал блоки. Сразу важное отступление. Beduin — это Backend-Driven UI. Если в нативе в коде клиентского приложения есть компоненты, бэкенд присылает им данные, и всё работает. В Beduin бэкенд присылает и данные, и сами компоненты в специальном виде. На клиенте у нас только рендерер — специальный компонент, который принимает JSON и рендерит то, что мы прислали. В этой статье я расскажу, зачем вообще переписывать работающую страницу, как эволюционировала наша архитектура и с какими компромиссами между нативным кодом и BDUI нам пришлось столкнуться. Статья будет полезна frontend- и mobile-разработчикам, инженерам платформенных команд, архитекторам клиентских приложений и backend-разработчикам, которые внедряют Backend-Driven UI. В общем, всем, кто планирует переводить крупные экраны на BDUI и хочет заранее узнать, что может пойти не так. Спойлер: всё.
https://habr.com/ru/companies/avito/articles/1072198/
#javascript #json #bdui #frontend #BackendDriven_UI #Kotlin_DSL #архитектура_фронтенда #abтестирование
-
Backend-Driven UI для умного дома: как обучить сервер верстать интерфейсы
Привет, Хабр! Я Дмитрий, iOS-разработчик из команды Салют — мы делаем устройства и программное обеспечение для Умного дома Сбер. У нас много собственных устройств и ещё больше устройств брендов-партнёров, которые поддерживает платформа. Релизный круговорот фичей и интеграций заставляет думать: как оптимизировать процесс доставки новых функций пользователям? В статье расскажу про опыт разработки, внедрения и поддержки нашей собственной backend-driven UI парадигмы (BDUI) — подхода, в котором сервер управляет не только данными, но и вёрсткой интерфейсов.
https://habr.com/ru/companies/sberdevices/articles/1049570/
#iOS #Swift #SwiftUI #Android #Jetpack_Compose #BDUI #BackendDriven_UI #умный_дом #mobile #умныйдомСбер
-
«Это уже тысячу раз делали»: как мы добавили медиаленту в Яндекс Еду для iOS. А потом переделали
На первый взгляд, медиалента в мобильном приложении выглядит как стандартная задача: список карточек, автоплей, предзагрузка соседних роликов, несколько состояний загрузки. На практике это оказался один из самых сложных iOS‑компонентов, с которыми мне доводилось работать. Проблема в том, что медиалента — это не один виджет и не просто плеер внутри ячейки. Это система, которая живёт на пересечении сразу нескольких тяжёлых доменов: динамически собираемый интерфейс, сетевые ограничения, декодирование медиа, менеджмент памяти, жизненный цикл вложенных контейнеров, UX‑требования к мгновенному старту, интеграция в чужие экраны и такие сложные системы, как BDUI, рекомендации, пагинации, и при этом — высокий трафик на массовом сценарии. Само собой, любая ошибка в этой конструкции редко проявляется как локальный баг. Обычно она масштабируется: фризы при скролле, чёрные экраны, нестабильный автоплей, рост памяти на длинных списках, нагрев устройства и трудноуловимые падения, которые воспроизводятся только на части устройств и только в условиях реального использования, а не эмуляции. Самое интересное в таких задачах начинается не на этапе «как добавить медиаленту», а на этапе ограничений и деградаций. В статье я разберу именно эту сторону задачи на примере приложения Яндекс Еды: как мы проектировали медиаленту, какие архитектурные решения не сработали, какие баги всплыли только на реальных данных, как мы строили observability для дебага и какие компромиссы в итоге оказались эффективнее красивой реализации.
https://habr.com/ru/companies/yandex/articles/1048718/
#яндекс #ios #мобильная_разработка #интерфейсы #нагрузка #bdui #сеть #видео
-
Про BDUI грабли на примере простого опросника, который не так прост, как кажется
Однажды у нас появилась задача, которая (на первый взгляд) выглядела очень простой: сделать опросник в приложении. На макетах всего лишь пара экранов, несколько вопросов, кнопка «Далее». Всё красиво, не сухо, с картинками у вариантов ответа и нормальной подачей, а не в формате «Заполните обязательные поля» Судя по макету всё просто: сверстать флоу и отправить все ответы одним POST в конце. Самый короткий путь — зашить вопросы, переходы и тексты на клиенте. Делов на пару дней — сделал и забыл. Но если опросник перестаёт быть одноразовой анкетой, а становится частью живого продукта, начинается веселье: сегодня нужно поменять текст, завтра - картинку, потом - порядок вопросов, потом - ветвление, потом - похожий сценарий для другой группы пользователей. Каждая правка текста, картинки, порядка вопросов или маршрута снова уезжает в релизный цикл web, iOS и Android. А синхронизировать такие изменения между тремя платформами намного сложнее, чем кажется на старте. По некоторым косвенным признакам мы понимали, что с этой анкетой всё будет именно так, поэтому в качестве альтернативы мы выбрали путь backend-driven UI, когда клиент показывает поддерживаемые типы экранов, а backend управляет сценарием: текстами, изображениями, порядком шагов, переходами и состоянием прохождения. Ниже расскажу почему мы пошли в backend-driven подход, где он действительно помог, а где показал явные ограничения и мог выбить нас из сроков.
https://habr.com/ru/companies/alfa/articles/1036748/
#bdui #мобильная_разработка #системный_анализ #backendразработка
-
Не всё деплоем правится: как мы вынесли интерфейс из кода с помощью Server-Driven UI
Изменения интерфейса мобильного приложения часто упираются не в сложность реализации, а в скорость релизного цикла: даже простые правки проходят через полный конвейер — разработку, рецензирование, сборку и публикацию. При высокой частоте изменений это увеличивает time-to-market, перегружает команду и делает быстрые итерации по интерфейсу практически невозможными. Меня зовут Михаил Рыбочкин, я бэкенд-разработчик в компании GRI. Участвую в разработке и поддержке платформы для крупного ювелирного ритейлера. Я расскажу, как реализован Server-Driven UI для интернет-торговли с более чем 1000 розничных магазинов; как устроено управление конфигурацией интерфейса через Django Admin и как это позволяет менять интерфейс без релизов приложения; какие у этого подхода есть ограничения и какой инцидент произошёл в эксплуатации. Особенность нашего подхода в том, что SDUI одновременно обслуживает и нативные мобильные приложения, и веб на Vue. Один конфиг, один API, две целевых платформы
https://habr.com/ru/companies/gri/articles/1026592/
#SDUI #BDUI #вебразработка #backend #django #serverdriven_ui
-
Разбираем Remote Compose: как Google предлагает строить BDUI
Технологии Backend-Driven UI уже давно используются во многих компаниях, включая Альфа-Банк. Существует множество реализаций этого подхода, и недавно Google представил собственное решение — Remote Compose . Remote Compose выглядит очень перспективной технологией. Фреймворк активно развивается и поддерживается командой Google. Однако на момент написания статьи технология всё ещё находится в alpha-версии, поэтому использовать её на проде пока рано. Но я изучил этот фреймворк и хочу поделиться своим опытом,а когда Remote Compose выйдет в бета-версию вы будете знать, как с ним работать В статье разберём: — общую концепцию Remote Compose, — чем он отличается от классического BDUI, — какие интересные технические решения используются внутри, — несколько практических примеров использования.
https://habr.com/ru/companies/alfa/articles/1018986/
#android #compose #jetpack_compose #bdui #sdui #google #backenddriven_ui #remote_compose #compose_remote
-
Backend-driven UI в Авито: от идеи к проду
Всем привет! Меня зовут Влад Шатиленко, я продакт-менеджер в команде технической платформы Авито . Раньше я был разработчиком: начинал с аутсорса, затем работал в стартапе, где со временем перешёл в продакты. Сейчас в Авито занимаюсь развитием инструментов backend-driven UI — о них и пойдёт речь дальше. Статья будет полезна командам, которым важны скорость экспериментов, быстрые изменения интерфейса и кроссплатформенность.
https://habr.com/ru/companies/avito/articles/997010/
#mobile #bdui #avito #avitotech #авито #мобильная_разработка
-
Как мы перевернули подход к мобильным интерфейсам с Backend Driven UI
После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении. В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним. Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды. Такой подход работал, статусная модель была простой: несколько базовых состояний и переходы между ними. Но с ростом бизнеса логика усложнилась. Появились региональные особенности работы в разных городах, ролевые ограничения, условные переходы, зависящие от контекста. Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы. Читать про формирование UI через бэкенд
-
Два года с Duit — история взросления фреймворка
Когда-то Duit был всего лишь экспериментом — попыткой упаковать интерфейс Flutter в JSON и заставить его ожить. Сегодня это уже не технический трюк, а осмысленный подход к тому, как можно описывать UI данными, а не кодом, создавая управляемые интерфейсы нового поколения. Новый релиз — история взросления и поиска архитектурного баланса. За два года проект прошёл путь от набора идей до зрелой архитектуры, где принципы гибкости, тестируемости и производительности стали фундаментом проекта. Приглашаю тебя прочитать статью и узнать, как Duit v4 меняет представление о том, каким может быть BDUI-фреймворк.
https://habr.com/ru/articles/963884/
#bdui #sdui #duit #flutter #dart #mobile_development #framework #ui
-
BDUI: эволюция динамических интерфейсов
Привет, Хабр! В России набирает популярность новый подход к созданию пользовательских интерфейсов — Backend Driven UI (BDUI). В нём сервер задаёт структуру и поведение интерфейса, а приложение просто отображает его на экране. BDUI уже используют в своих приложениях многие коллеги из индустрии. Меня зовут Елена Зеликсон, я старший инженер по тестированию в VK. О том, какие преимущества у этого решения и как его применять, подробнее расскажу в этой статье.
-
Фронтенд и бэкенд больше не будут общаться как прежде: создаём конструктор сценариев на базе Backend Driven UI
Цикл продуктовой разработки часто напоминает весы: с одной стороны, системное проектирование, подбор основополагающих инструментов, масштабные рефакторинги. С другой — совокупность локальных решений, принимаемых для точечных улучшений в системе. И самое сложное тут: соблюдать баланс. Как понять, когда имеет смысл вмешаться «хирургически», а когда — предпочесть вместо конкретной проблемы решить (или предотвратить) целый класс проблем? Иногда нащупать границу между «масштабом» и «целесообразностью» получается почти что случайно. Однажды мы в Сравни подступились к переделке чата в нашем мобильном приложении, и на старте расценивали задачу как «ещё один рядовой продуктовый кейс». Но планы по модификации фичи быстро переросли в создание универсального инструмента: конструктора сценариев на базе Backend Driven UI. В итоге мы не просто заменили чат более удобной альтернативой, а в целом научились гибко управлять фронтендом приложения . Со всеми сопутствующими плюсами как для бизнеса, так и для самих разработчиков (теперь, чтобы реализовать некоторые изменения на экранах, даже не обязательно быть фронтендером или мобильным разработчиком!). Подробности о нашем сценарном BDUI-движке — этапах его создания, вариантах использования и нюансах технического устройства — читайте под катом.
https://habr.com/ru/companies/sravni/articles/912896/
#backendразработка #bdui #nodejs #typescript #server_driven_ui #архитектура_приложений
-
Большое обновление DivKit: визуальный редактор, поддержка форм, аниматоры
Почти три года назад мы выложили в опенсорс DivKit — наш BDUI‑фреймворк для отрисовки интерфейса приложения из ответа сервера. С его помощью вы можете описать элементы, состояния и анимации на бэкенде. Приложение получит это JSON‑описание и отобразит его. Мы не перестаём развивать DivKit и за последние месяцы добавили несколько важных функций. О них расскажем в статье.
-
Как улучшить UX в PWA на React с помощью потокового Backend-Driven UI — личный опыт
Хочу показать три приёма, как можно ускорить загрузку интерфейсов с Backend-Driven UI и улучшить UX. Решения показали хорошие результаты на демо-версии, но увы, пока ещё не внедрены в реальный проект. Было бы интересно обсудить с вами, как эти приёмы могут помочь в боевых задачах и что ещё можно улучшить.
https://habr.com/ru/companies/outlines_tech/articles/905166/
#BackendDriven_UI #bdui #ux #интерфейс #долгая_загрузка #парсинг #Медленная_загрузка #ускорить_интерфейс #Потоковая_загрузка #Частичный_парсинг
-
Как мы сокращали размер JSONʼа в SDUI
Привет, хабрачитатели! Server-Driven UI (SDUI) — это подход, при котором сервер управляет отображением интерфейса на клиенте. Важное преимущество SDUI — возможность внедрять изменения без выпуска новых версий приложений. Но это же преимущество есть его недостаток, ведь передача всех данных по сети зависит от качества соединения и увеличивает объём данных. Качество связи мы не можем контролировать, а вот уменьшить количество передаваемой информации посредством сокращения JSON, — вполне.
-
Современные подходы к управлению UI: low-сode & Backend-Driven UI
Привет, меня зовут Михаил Шевченко. В Авито я проектирую и разрабатываю backend low-code платформы Bricks. В этой статье рассказываю о том, почему в Авито было принято решение развивать собственные low-code-решения и Backend-Driven UI, объясняю их устройство и делюсь достигнутыми результатами.
https://habr.com/ru/companies/avito/articles/879720/
#BDUI #интерфейсы #backend_driven_ui #android #ios #мобильные_приложения #mobile_development #backend_driven #low_code #lowcode
-
BDUI — это спасение от релизов: «Какие ваши доказательства?»
Если вы видели no-code-проекты, где можно просто блоками перетаскивать интерфейс, то отчасти вы уже знакомы с BDUI-подходом, ведь они по сути и построены на BDUI. Суть в том, что мы делегируем наполнение интерфейса серверу. Фронтенд не отвечает за то, что будет нарисовано, а только определяет список допустимых компонент, которые сервер может показать пользователю. Но в вебе BDUI не очень популярен. А зря. Ведь в первую очередь он нужен как спасение от релизов. Но, если быть точнее, он нужен как средство для снижения количества релизов, затрат на разработку и выкатку фичей. Давайте это и обсудим, а также как работает BDUI, разберём примеры, реализованную фичу, которую мы недавно релизили, посмотрим на другие варианты реализации и подведём итоги. Вряд ли узнаете, как на 100 % реализовать или внедрить BDUI в свой проект, ибо это слишком категорично, потому что для каждого проекта всё индивидуально. Но… об этом я и расскажу в моей обзорной «лекции».
-
Один год с Duit — ретроспектива развития
Ровно год назад был сделан первый коммит в репозиторий проекта, который во многом определил вектор моих профессиональных интересов, изысканий и приложения сил. 16 ноября 2023 года я начал работу над BDUI-фреймворком для Flutter - Duit . Это был длинный путь и в этой заметке я хочу рассказать вам об этом захватывающем приключении.
-
Шпаргалка с основами BDUI для продуктовых дизайнеров
Большая статья в двух частях о самом важном, что нужно знать и учитывать продуктовому дизайнеру, если проект, над которым он работает, будет реализован на BDUI: — в чём его суть и чем он отличается от классического подхода в разработке; — что такое контракт экрана и контракт компонента, почему они главный источник истины в BDUI подходе, и как с ним работать дизайнеру; — как дизайнеру читать JSON, разберём ключи и значения. Статья будет не только теоретической. Поделимся своим опытом внедрения BDUI в дизайн-процессы с примерами и иллюстрациями и оставим несколько рекомендаций для тех, кто только начинает делать это у себя в продукте или команде.
-
BDUI: удовольствие или боль
Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных. На первый взгляд, это даёт несколько преимуществ. Во-первых, сокращается время от идеи до реализации фичи. Во-вторых, можно создать интерфейсы сразу для нескольких платформ. В-третьих, появляется возможность обновлять функциональность без необходимости обновления приложения, даже на старых версиях у пользователей. На бумаге такие идеи кажутся идеальными, иногда даже «серебряной пулей». Однако на практике всё не так однозначно, и многое зависит от конкретного кейса. В этой статье я поделюсь опытом нашей компании, расскажу о нюансах, которые позволили нам извлечь пользу из BDUI, и представлю рабочий инструмент. Мы использовали нестандартные подходы, которые, надеюсь, вдохновят вас. Похоже, что для нас BDUI — это скорее удовольствие, чем боль. Давайте разберёмся, как нам это удалось!
https://habr.com/ru/companies/cian/articles/840664/
#программирование #bdui #разработка_под_android #разработка_под_ios #ios #android #интерфейсы #мобильные_приложения #мобильная_разработка
-
Следим за производительностью SDK. Доклад Яндекса
Влад Бардин, iOS‑разработчик в команде Яндекс Маркета, выступил с докладом конференции Яндекс Go Dev Day&Night. Он рассказал, зачем следить за производительностью, когда вы разрабатываете такой фундаментальный SDK, какие метрики стоит собирать и как взаимодействовать с потребителями, а именно с продуктовыми командами, которые используют ваш SDK в своих приложениях.
https://habr.com/ru/companies/yandex/articles/841086/
#bdui #мобильная_разработка #мобильные_приложения #интерфейсы #sdk #метрики
-
Собираем данные из сотни микросервисов, или Как мы разобрали Ozon на кубики, а потом собрали заново
Всем привет! Меня зовут Саша, я руковожу группой разработки Composer Core в Ozon Tech. В этой статье я расскажу о том, как устроена пользовательская часть одного из ведущих российских маркетплейсов, в развитии которой на момент написания статьи участвуют сотни специалистов из десятков команд. При наличии такого количества людей разрабатывать новую функциональность, не рискуя сломать уже существующую, является достаточно сложной задачей. Поделюсь подходами, которые позволили нам организовать взаимодействие большого количества сервисов доменных команд для формирования общих ответов пользователю. При этом менять содержимое страниц можно буквально по щелчку пальцев, а значит, быстро адаптироваться к постоянно меняющимся требованиям бизнеса. Продукт, который мы разработали, вряд ли когда-нибудь станет open-source-проектом, так как он слишком зависит от специфики инфраструктуры Ozon Tech. Но основные принципы могут быть полезны при проектировании похожих систем.
-
Корпоративная магистратура ИТМО и Яндекса: как всё устроено
Корпоративная магистратура Яндекса работает в ИТМО уже второй год. Конечная цель программы ― еще на этапе обучения дать практический опыт, необходимый для работы в коммерческой разработке. Магистранты программы решают не абстрактные задания из учебника, а реализуют проекты, которые потом попадают на прод в проектах Яндекса ― в том числе в Open Source. В статье рассказываем, как всё устроено и над чем работают студенты.
https://habr.com/ru/companies/spbifmo/articles/829412/
#divkit #опенсорс_яндекса #bdui #магистратура #университет_итмо #университеты #svg #framework
-
Как мы строили BDUI: опыт Яндекс Маркета
Привет! Меня зовут Алексей Морозов. Я уже несколько лет работаю в инфраструктурной команде Яндекс Маркета. Наша команда делает проекты, которые должны были улучшить скорость приложения, его качество и скорость разработки. Однако раньше такие проекты решали эти проблемы только на время, приложение снова деградировало. Всё это напоминает древнегреческий миф, в котором Сизиф толкает в гору камень, он скатывается вниз, и всё начинается по новой. Такое положение дел нас не устраивало, поэтому было принято решение изменить подход. И мы построили BDUI (Backend Driven UI). В этой статье я расскажу о том, как это случилось, что сделали и какой в итоге получили результат.
https://habr.com/ru/companies/yandex/articles/819531/
#яндекс #яндексмаркет #bdui #sdui #ios #android #divkit #мобильная_разработка
-
Как я перешёл на тёмную сторону: путь из Андроида в бэкенд
Привет, Хабр! Меня зовут Андрей. 7 лет я разрабатываю под Android. Год назад я писал код для мобильного приложения банка и особо не задумывался о переходе на другие задачи. В один прекрасный день мне прилетела таска — добавить параметр в диплинк на Андроиде. Потом меня попросили добавить его ещё и на бэке. Я закоммитил, запушил, проверил — всё работает. Ребята в шутку предложили мне перейти в бэкендеры из Андроида. Тут я задумался, а шутка ли это, челлендж показался мне интересным. Расскажу о своих экспериментах с бэком в формате дневника — вдруг вы решите повторить мой опыт или поделитесь, как проходили этот путь сами.
https://habr.com/ru/companies/alfa/articles/791772/
#bdui #json #развитие_программиста #wiremock #backend #саморазвитие #мотивация_в_ит #продуктовая_разработка #kotlin
-
Практическая реализация паттерна Server-Driven UI на Flutter c использованием фреймворка Duit
Жизнь не становится проще, а публикация приложения в сторы и подавно. Задержки при проверках, неожиданные проблемы со стороны сторов и невозможность быстро доставить хот-фикс пользователям потрепали нервы многим поколениям мобильных разработчиков. Поэтому инженеры, разрабатывающие свои приложения под самые разные платформы, стараются всеми силами решить эти проблемы и сократить время доставки обновлений до пользователя. В рамках этой статьи мы попытаемся решить эти проблемы, взяв за основу один из популярных паттернов и создав демонстрационное Flutter приложение на базе Server-Driven UI фреймворка Duit.