Backend Driven UI: о трендовом подходе к созданию мобильных приложений
Представьте — вы пользуетесь приложением, а оно не просит вас постоянно обновляться. Вы можете пользоваться новыми функциями, а ваш клиентский опыт будет становиться только лучше. Это кратко о том, как работает BDUI. А теперь поподробнее.
Backend Driven UI — относительно новая, но уже популярная парадигма создания приложений. Фронт управляет бэком и может отрисовывать интерфейсы с нужным контентом в реальном времени.
BDUI позволяет сделать продукт индивидуально полезным для каждого пользователя. На личном опыте я убедился, что это очень важно в современном процессе мобильной (и не только) разработки.
Меня зовут Алексей Матвеев, я проектирую мобильные решения около 15 лет, на данный момент являюсь директором по мобильным технологиям в компании «Первая Форма». BDUI-подход мы фактически начали применять ещё в 2016 году. В частности, на нём построена наша мобильная платформа, которая легла в основу супераппа для экосистемы «Сколково».
В статье я постараюсь подсветить ключевые аспекты концепции, оценить её пользу для процесса разработки и бизнеса. Ближе к концу приведу реальные примеры применения BDUI в наших проектах. Сразу оговорюсь, что фокус внимания будет на in-house потребностях построения корпоративных приложений.
Что будет в этой статье:
Что такое BDUI и почему он в тренде
BDUI — это парадигма разработки динамических приложений, где сервер управляет не только данными, но и вёрсткой интерфейсов и функциями, доступными разным ролям пользователей. Она позволяет индивидуально настраивать приложение в реальном времени.
В основе лежат четыре принципа:
- полная типизация всех объектов системы,
- управляющая дизайн-система,
- строгий контракт передачи структуры интерфейсов и бизнес-логики с бэка на фронт,
- версионируемое API.
Фронт — главный в формировании структуры данных и интерфейсов API. Бэк превращается в хранилище данных, схем, бизнес-логики. Он — центр администрирования процессов, построенных исходя из потребностей фронта, который несёт основную ценность потребителю.
При этом фронт и бэк развиваются независимо, и важно следить, чтобы новый фронт был совместим со старым бэком, и наоборот.
Пользователь же видит приложение как набор независимых модулей, доступных в зависимости от прав и предпочтений. При этом этот набор может сформировать архитектор рабочего места в конструкторе.
Все объекты системы имеют фиксированный набор настраиваемых представлений, а интерфейс строится из виджетов — небольших, встраиваемых в разный контекст, и сложных комплексных. Общий дизайн приложения определяется дизайн-системой.
Фактически на клиенте зафиксирован только общий каркас и базовая логика поведения. В остальном он получает инструкции по работе от сервера и динамически их интерпретирует — становится «браузером» функциональных сценариев.
Интерфейс и возможности одного и того же приложения могут отличаться для разных групп пользователей, подразделений, компаний. При этом любой настроенный в рамках возможностей текущего ядра платформы процесс может быть доступен для любого пользователя.
Плюсы BDUI для бизнеса
Сегодня в рамках BDUI-подхода свои продукты развивают Яндекс, Авито, Тинькофф, Озон и прочие IT-гиганты. За последние годы BDUI стал самостоятельным направлением больших IT-конференций, целиком посвященных этой теме. Поэтому рассмотрим ключевые плюсы подхода в разрезе каждодневных потребностей высокотехнологичной компании.
Быстрая доставка новых функций с минимальными затратами
Администратор системы полностью контролирует содержимое приложения. Он может включать и отключать функции сразу всем пользователям или группам, добавлять новые шаги, условия или ветвления в старые процессы, а изменения сразу появятся у пользователей.
Когда по миру гулял коронавирус, мы за вечер построили процесс сбора данных о вакцинации. Уже утром важный процесс был доступен сотрудникам компании из любого интерфейса.
Возможность быстрых глобальных изменений
Приложение работает с типизированными объектами по чётким инструкциям, поэтому нужно только задать бизнес-логику и визуализацию процесса в админ-панели.
Перед Новым Годом нам нужно было собрать с сотрудников данные о детях для подготовки поздравлений и подарков. Мы быстро настроили и запустили процесс, но в спешке забыли добавить пункт анкеты про интересы ребёнка. Поле мы добавили в действующую анкету, и оно появились даже у сотрудников, которые её уже заполнили.
В одном приложении можно создать сколько угодно рабочих мест со своим набором функций и дизайном
Пользователь может менять роли и даже совмещать несколько функциональных ролей. При выдаче определенных прав он сразу получает новые рабочие возмозможности и интерфейс.
Мультиролевая модель реализована в нашем супераппе для экосистемы «Сколково». В общей сложности все процессы структурированы для более чем 20 ролей. Для каждой роли продуман свой сервисный дашборд.
При скачивании приложения пользователь получает базовый набор функций гостевого режима: информационные виджеты, календарь мероприятий, возможность заказать такси и другое.
Как только, например, он арендует жильё, он получает роль «Житель». Она позволяет обращаться в управляющую компанию, оформлять пропуска для машин и ещё много чего.
Большой простор для маркетинговых, процессных и UX-исследований
BDUI позволяет тестировать различные гипотезы, быстро запускать пилотные и интеграционные проекты, брендировать приложение для подразделений, компаний и партнёров. Для этого достаточно создать новую роль и настроить для нее функциональную и визуальную части.
Пересматривая программу онбординга, мы выбирали, как лучше подать большой блок о возможностях системы: сразу погрузить новичков в детали или сократить информацию. Мнения в проектной команде разделились, и мы запустили A/B-тестирование, разделив новых пользователей на группы. После этого мы поняли, на каком из вариантов лучше остановиться.
Конструирование удобных интерфейсов «на лету»
Динамика BDUI помогает кастомизировать и адаптировать сложные процессы, не потеряв в функциональности. Мы можем строить простые ролевые интерфейсы для решения конкретных задач (с учётом особенностей различных фронтов). При этом в приложении не будет информационной перегрузки и глобальной «резиновой» вёрстки для любого фронта.
В качестве простейшего примера — постановка отсутствий в календарь. Интерфейсы имеют некоторые различия, исходя из обзорных возможностей, но решают одну задачу. В любой момент можно глобально и независимо изменить каждый из них.
Минусы BDUI
Безусловно, идеальных решений не бывает. BDUI накладывает ограничения: быстро, гибко и красиво — тут зачастую приходится жертвовать одним из трёх условий. Можно было бы в этот ряд поставить также «дешево», но, как я упоминал в разделе плюсов, экономия ресурсов при внедрении — одна из важнейших составляющих подхода.
- Для развития системы сложнее найти кадры. В идеале BDUI подразумевает, что фронт-разработчик получит в управление бэк — частично или полностью. Тут не подойдёт привычный фулстек-подход (от бэка к фронту), нужно мыслить как архитектор прикладных процессов, спускать UI/UX-концепции с фронта на бэк.
- Типизация и жёсткость контактов фронта и бэка ограничивают возможности визуализации. Мы можем очень быстро запустить процесс на текущем конструкторе, но если понадобятся принципиально новые возможности, то придётся синхронно развивать систему. При этом принципиальные нововведения будут доступны только в новом релизе.
Суперапп для экосистемы «Сколково» вырос из потребностей пользователей, чьи дети учатся в Международной Гимназии. Функции были ограничены, что местами сильно упростило архитектуру и ускорило запуск проекта.
Но в дальнейшем стали появляться новые функциональные потребности, пришлось выбирать. Мы могли делать долго с полной обратной совместимостью старых и новых релизов или перейти на архитектуру 2.0. Но для этого нужно было, чтобы все пользователи обновили старые версии приложения для полноценной работы.
В ближайшем будущем мы готовим большое обновление приложения, почитать можно тут.
- Нужно соблюдать баланс между многообразием возможностей и простотой настройки системы. Если слишком глубоко уйти в кастомизацию интерфейса, то в конечном счёте можно получить сложную систему, которая в неумелых руках администратора даст построить чрезмерно сложный процесс с сомнительным UX.
У нас есть клиент, чьи администраторы, пройдя наше базовое обучение, теперь сами настраивают процессы, зачастую сильно перегружая их. В результате этой избыточности может страдать быстродействие. В итоге решать эту проблему приходится нам либо через какие-то структурные оптимизации, либо даже через запреты на определённые настройки.
Философия нашей BPM-системы заключается в оперативном решении любых задач заказчика. Поэтому в зависимости от ситуации чаще возникает выбор между «гибко» и «красиво».
В современном мире «быстрый» чаще побеждает «умного». Скорость — ключевое преимущество подхода BDUI. Правда, чтобы обрести её без ущерба функциональности, сначала нужно пройти существенный путь становления. Вот как это было у нас.
Low-code на службе BDUI
«Первая Форма» занимает лидирующие позиции в рейтинге low-code BPM-систем на российском рынке. Low-code подход обеспечивает существенную гибкость и функциональность нашим приложениям. С ним любые интеграции и настройки процессов можно реализовать проще и без привлечения разработчика платформы (то есть существенно быстрее и дешевле).
Итак, что же под капотом «Первой Формы»?
Функциональность iOS/Android-версий повторяет вэб, насколько позволяют размеры экранов и технические возможности устройств.
В базе в приложении есть мессенджер, аудио/видео звонки и ВКС, таск-трекер, работу с подписями, включая ЭП, календарь, почтовый клиент, распознавание документов и многое другое.
- Работать можно в рамках различных лицензионных политик, сразу с нескольких учётных записей на разных серверах.
- Клиент получает базовое решение, которое можно наполнить любыми процессами индивидуально для каждой роли в компании. На старте проекта этим всегда занимаемся мы, но в дальнейшем подхватить эстафету могут прошедшие у нас обучение администраторы со стороны клиента.
- Единое приложение работает с in-house инсталляциями на серверах клиентов и совместимо даже с бэками двухлетней давности.
- Можно выпускать независимые брендированные версии приложения по запросу клиента. Важно, что это не только повышает статус бренда в глазах сотрудников и партнёров, но и положительно влияет на стабильность и минимизирует проблемы при выходе новых версий: ключевой набор функций нового релиза можно детально перепроверить и решить процессные проблемы ещё до выпуска.
Кроме всех этих компонентов в нашем BDUI-подходе мы активно используем механизм динамического API и Lua-скрипты. Рассмотрим их подробнее.
Платформа в целом типизирована, построена на жестких контрактах и имеет богатое фиксированное REST API. Тем не менее, при внедрении системы клиентам регулярно возникает необходимость настраивать интеграции со сторонними сервисами и прописывать кастомные сценарии поведения приложения.
Для этих задач можно в любой момент дополнить API динамическими запросами. Новый метод примет определённый набор данных, обработает их по нестандартной логике и сформирует BDUI-сценарий для отработки в приложении.
Являясь очень простым по сути, язык Lua позволяет писать real-time сценарии работы с прямым доступом к данным системы. Он отлично подходит для быстрого написания сложных логических сценариев обработки данных и позволяет на лету формировать JSON-ответы. Альтернативы, конечно, есть, но тот же SQL-подход на практике оказывается более громоздким и предъявляет повышенные требования к квалификации разработчика.
Предположим, есть сторонний сервис новостей, а мы не хотим делать полноценную затратную интеграцию, заводить процесс и все сущности для синхронизации в нашей базе данных и так далее. Тогда мы делаем простое прокси-решение:
1. Публикуем новый метод для получения ленты новостей.
2. Под капотом на Lua формируем сетевой запрос к стороннему сервису, обрабатываем полученные данные, формируем необходимую типизированную отдачу.
3. Через админ-панель приложения настраиваем новый виджет новостей на базе нового метода.
Всё! При открытии приложения пользователь видит новости из стороннего сервиса.
Химия между BDUI и low-code
Любая система-конструктор строится на базовых сущностях. И при решении любой нестандартной задачи возникает вопрос: расширять ли текущий набор сущностей или воспользоваться такими парадигмами, как протокол, адаптер или даже «вью-модель». Мы пошли вторым путём.
Зачастую данные совершенно разной природы можно и даже нужно представить в едином виде. Но случается и обратная задача — создать разные представления одной и той же сущности.
В нашей системе есть набор статических и параметрических представлений данных. Мы используем их в разных контекстах: список, агрегация, создание и показ сущности. Конечный вид зависит от процесса и от пользователя, который в нём работает.
Например, в виде списка можно показать:
- компании на основе данных CRM,
- коллег, у которых скоро день рождения,
- платёжные поручения из внешней системы.
В первом случае мы используем типовую архитектуру системы и через API передаём список базовых сущностей («задач») из модуля CRM.
Во втором мы работаем со списком сущностей типа «пользователь». Для получения есть отдельный метод API, но стандартное представление, очевидно, другое. Поэтому мы добавляем на лету новый метод API, который содержит Lua-адаптер для представления данных сущности «пользователь» в виде «задачи». В итоге мы получаем адаптивную модель данных для показа в нужном представлении.
Приложению при этом совершенно не важно, какой метод API вызывать для решения задачи. Ключевой момент, что оно получило понятную структуру данных и представлений, достаточную для безошибочной интерпретации и визуализации. Дополнительно мы можем переопределять и взаимодействие пользователя с полученным контентом.
Третья задача похожа на вторую. Но здесь мы дополнительно осуществляем интеграцию с внешней системой, из которой Lua-скрипт должен сначала получить исходные данные, после «переупаковать» их по правилам системы и сформировать JSON ответ. И это всё без настройки сложной интеграции между системами.
Любая клиентская потребность как часть платформы: кейс «Спортмастер»
Расскажу, как мы по запросу клиента внедряли функцию «Чек-лист». Была поставлена задача построить процесс проверки готовности торговых залов к работе с фиксацией недостатков и постановкой поручений по их исправлению.
В самом простом случае, без зависимостей и ветвлений, чек-лист можно представить как таблицу Excel. В каждой строчке с вопросом мы можем добавить ответ, комментарии, приложить какие-то подтверждающие файлы. Так мы реализовали параметрическое представление чек-листа на основе базовой сущности «таблица».
Из API-запроса клиент получает информацию о визуальной интерпретации приходящих данных — должна ли это быть просто таблица для заполнения, или это технологичный чек-лист с удобным интерфейсом.
Все данные находятся в системе, и благодаря low-code настройкам клиент может прямо по ходу заполнения чек-листа запускать смежные процессы: например, автоматически поставить задачу специалистам хозяйственной службы на уборку зала.
В итоге любой процесс в системе можно обогатить функциональностью чек-лист несложными настройками на сервере.
Например, у нашего отдела продаж, тоже есть свой чек-лист, для подготовки ко встрече с клиентом. Менеджеры вносят в него текущие потребности и особенности клиента, а по результатам заполнения запускаются связанные процессы на основе собранных данных.
Суперапп SkolCity
Как я уже рассказывал, несколько лет назад к нам пришёл запрос на автоматизацию процессов Международной Гимназии «Сколково». Нас просили создать мобильное приложение, которое объединило бы учителей, родителей и различные службы гимназии. Этот внутренний портал должен был включать соцсеть для участников и набор внутренних административных сервисов.
Установочная встреча прошла в июле, а уже 1 сентября мы выпустили первую версию приложения SkolCity, в котором оцифровали ключевые процессы Гимназии. Со временем их количество существенно выросло, например, мы добавили:
чаты для общения родителей и учителей по классам, частых вопросов, консультаций с тьютором и психологом;
новости и календарь мероприятий;
- информацию по дополнительному образованию и возможность записаться в секции;
- формирование платежных поручений за обучение;
- личный кабинет родителя, где можно управлять профилями детей, заказывать справки, проверять льготы и управлять списком доверенных лиц;
- журнал контроля посещаемости по пропускам и многое другое.
Вскоре подключиться к приложению захотели и другие подразделения «Сколково». Сегодня им пользуются сотрудники Технопарка, арендаторы жилья, центральная диспетчерская, эксперты Фонда и даже его вице-президент. Многие при этом имеют доступ к нескольким функциональным блокам супераппа, так как снимают апартаменты, работают в Технопарке, а их дети обучаются в Гимназии.
Искать ли альтернативу BDUI или «лучшее — враг хорошего»?
Основные принципы современного IT-подхода — делать быстро, экономично, гибко, с возможностью переиспользовать результаты. Чем больше типовой работы можно сделать без участия разработчика, тем лучше.
И в этом плане подход BDUI отлично зарекомендовал себя. Недаром все крупные компании активно развивают свои практики и регулярно делятся друг с другом достижениями на профильных конференциях.
Но это, конечно, не означает, что любое приложение нужно априори строить на этих принципах. Экономическая составляющая архитектуры проекта очень важна, а также многое зависит от класса решаемых задач.
В любом случае, важно вовремя переориентировать проект в BDUI-направлении. Мне кажется, что уже не за горами его интенсивное развитие, и потому пора минимизировать подходы уровня «copy/paste» и «monkey job».
Поставьте лайк, если дочитали до конца
Как сторы смотрят на BDUI? Потенциально это даёт лазейку для разного рода казино и т.п. и по этой причине GP не пропускал раньше подобные приложения
Сторы в первую очередь полагаются на тестирование при модерации и разработчики заявленное соответствие политик, обозначенных в приложении.
Систематической процедуры выявления нет, но все работают по инцидентам, и наказанием может быть потеря аккаунта.
Сейчас, конечно, смотрят строго на потенциально санкционные моменты.
Но даже условное «калькуляторы», содержащие под капотом банк, могли бы сидеть в сторе дольше, если бы не активная реклама таких размещений, чтобы клиенты успели обновиться за считанные дни, а то и часы.
Это действительно Deep in Mobile!
хороший разбор