Backend Driven UI — относительно новая парадигма создания приложений. Она позволяет сделать продукт индивидуально полезным для каждого пользователя. На личном опыте я убедился, что это очень важно в современном процессе мобильной (и не только) разработки.

Меня зовут Алексей Матвеев, я проектирую мобильные решения около 15 лет, на данный момент являюсь директором по мобильным технологиям в компании «Первая Форма». Мы разрабатываем масштабную BPM-систему, а сам BDUI-подход фактически начали применять ещё в 2016 году. В частности, на нём построена наша мобильная платформа, которая легла в основу супераппа для экосистемы «Сколково». 

В данной статье я постараюсь подсветить ключевые аспекты концепции, оценить её пользу как для процесса разработки, так и для бизнеса. Ближе к концу приведу реальные примеры применения BDUI в рамках наших проектов. Сразу оговорюсь, что фокус внимания будет на in-house потребностях построения корпоративных приложений.

В статье:

Краткая история архитектуры корпоративных приложений
Что такое BDUI и почему он в тренде
Плюсы и минусы BDUI для бизнеса
История развития BDUI в «Первой Форме»
Low-code на службе BDUI
Любая клиентская потребность как часть платформы: кейс «Спортмастер»
Суперапп SkolCity

Краткая история архитектуры корпоративных приложений

Изначально, в эпоху первичного глобального вэба, отдельного фронта как такового не было. За логику и дизайн целиком отвечал бэк, который объединял данные и вёрстку экранов и посылал на фронт, в браузер. Там и происходила безусловная отрисовка очередного экрана «as is».

Затем на фронте стал активно использоваться JS для локальных изменений контента прямо в браузере. Часть бизнес-логики и изменений интерфейса стала динамической, но экраны в целом по-прежнему собирались на сервере.

Потом пришла эпоха нативных мобильных приложений под iOS и Android — она полноценно разделила вёрстку (интерфейс) и данные, получаемые через API. Экраны уже формировались на уровне приложения, но существенная часть динамики интерфейса и логики обработки данных фиксировалась на момент сборки очередного релиза.

Логика построения нативных приложений безусловно повлияла на развитие вэб-приложений. Так, появились PWA-приложения, которые фактически повторяют архитектуру нативных, используя JS-фреймворки (AngularJS или ReactJS).

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

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

Вот здесь-то и произошла смена парадигмы — появилась концепция Backend-Driven UI (или Server-Driven UI), коротко — BDUI.

Что такое BDUI и почему он в тренде

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

В основе лежат четыре принципа:

1. полная типизация всех объектов системы,

2. управляющая дизайн-система,

3. строгий контракт передачи структуры интерфейсов и бизнес-логики с бэка на фронт,

4. версионируемое API.

Ключевую роль в формировании структуры данных и интерфейсов API играет именно фронт. Бэк становится хранилищем данных, схем, бизнес-логики, центром администрирования процессов, построенных исходя из потребностей фронта, который несёт основную ценность потребителю. 

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

Конечное приложение для пользователя представляет собой набор независимых модулей, доступных в зависимости от прав и предпочтений пользователя, а также задумки архитектора рабочего места на основе имеющегося конструктора.

Все объекты системы имеют фиксированный набор настраиваемых представлений, а интерфейс строится из виджетов — небольших, встраиваемых в разный контекст, и сложных комплексных. Общий дизайн приложения определяется дизайн-системой.

Фактически на клиенте зафиксирован только общий каркас и базовая логика поведения. В остальном он получает инструкции по работе от сервера и динамически их интерпретирует — становится «браузером» функциональных сценариев.

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

В итоге, данный подход идеально подходит по своему духу для построения максимально гибкой и динамичной BPM-системы.

Плюсы BDUI для бизнеса

Сегодня в рамках BDUI-подхода свои продукты развивают Яндекс, Авито, Тинькофф, Озон и прочие IT-гиганты. За последние годы BDUI стал самостоятельным направлением больших IT-конференций, целиком посвященных этой теме. Поэтому рассмотрим ключевые плюсы подхода в разрезе каждодневных потребностей высокотехнологичной компании.

Быстрая доставка новых функций с минимальными затратами

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

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

Возможность быстрых глобальных изменений

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

Перед Новым Годом нам нужно было собрать с сотрудников данные о детях для подготовки поздравлений и подарков. Мы быстро настроили и запустили процесс, но в спешке забыли добавить пункт анкеты про интересы ребёнка. Поле мы добавили в действующую анкету, и оно появились даже у сотрудников, которые её уже заполнили.

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

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

Мультиролевая модель реализована в нашем супераппе для экосистемы «Сколково». В общей сложности все процессы структурированы для более чем 20 ролей. Для каждой роли продуман свой сервисный дашборд.

При скачивании приложения пользователь получает базовый набор функций (гостевой режим): информационные виджеты, календарь мероприятий, общие сервисные функции (заказ такси, поиск кафе, подбор апартаментов для проживания). Как только, например, он арендует жильё, он получает роль «Житель», после чего может обращаться в управляющую компанию, оформлять пропуска для машин и ещё много чего.

Большой простор для маркетинговых, процессных и UX-исследований

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

Пересматривая программу онбординга, мы выбирали, как лучше подать большой блок о возможностях системы: сразу погрузить новичков в обилие деталей или сократить информацию. Мнения в проектной команде разделились, и были запущены оба варианта в рамках A/B-тестирования, разделив новых пользователей на группы. После этого проведя интервью с пользователями, мы поняли, на каком из вариантов лучше остановиться.

Конструирование удобных интерфейсов «на лету»

Динамика BDUI помогает кастомизировать и адаптировать сложные (иногда весьма громоздкие) процессы, не потеряв в функциональности. Мы можем строить простые ролевые интерфейсы для решения конкретных задач (с учётом особенностей различных фронтов), избегая информационной перегрузки и глобальной «резиновой» вёрстки для любого фронта, соблюдая общую консистентность. 

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

Минусы BDUI

Безусловно, идеальных решений не бывает. BDUI накладывает ограничения: быстро, гибко и красиво — тут зачастую приходится жертвовать одним из трёх условий. Можно было бы в этот ряд поставить также «дешево», но, как я упоминал в разделе плюсов, экономия ресурсов при внедрении — одна из важнейших составляющих подхода.

• Для развития системы сложнее найти кадры. BDUI подразумевает (в максимальной формулировке), что фронт-разработчик получит в управление бэк — частично или полностью. Тут не подойдёт привычный фулстек-подход (от бэка к фронту), нужно мыслить как архитектор прикладных процессов, спускать UI/UX-концепции с фронта на бэк.

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

Суперапп для экосистемы «Сколково» вырос из потребностей пользователей, чьи дети учатся в Международной Гимназии. Функции были ограничены, что местами сильно упростило архитектуру и ускорило запуск проекта. Но в дальнейшем стали появляться новые функциональные потребности, что привело к необходимости выбора: делать долго с полной обратной совместимостью старых и новых релизов или перейти на архитектуру 2.0 с обязательным обновлением всех старых версий приложения для полноценной работы. 

В ближайшем будущем мы готовим большое обновление приложения, почитать можно тут.

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

У нас есть клиент, чьи администраторы, пройдя наше базовое обучение, теперь сами настраивают процессы, зачастую сильно перегружая их. В результате этой избыточности может страдать быстродействие. В итоге решать эту проблему приходится нам либо через какие-то структурные оптимизации, либо даже через запреты на определённые настройки.

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

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

История развития BDUI в «Первой Форме»

Первые BDUI попытки мы предприняли еще в 2016 году. Шла большая многодневная бизнес-конференция, где важной составляющей было мобильное приложение, и было нужно с его помощью буквально в течение каждого дня фокусировать пользователей на определенных задачах.

Тогда всё решалось на уровне простой JSON-схемы описания интерфейса, которую приложение получало при очередном старте. Не было админ-панели, дизайн-системы, но уже был заложен принцип типизированного конструктора. Я осознал, что могу гибко управлять структурой приложения буквально в real-time без регулярных призывов обновляться. 

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

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

Итак, что же под капотом мобильного приложения «Первой Формы»?

• Функциональность iOS/Android-версий повторяет вэб, насколько позволяют размеры экранов и технические возможности устройств.

• В базе в приложении есть мессенджер, аудио/видео звонки и ВКС, таск-трекер, работу с подписями, включая ЭП, календарь, почтовый клиент, распознавание документов и многое другое.

• Работать можно в рамках различных лицензионных политик, сразу с нескольких учётных записей на разных серверах. 

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

• Единое приложение работает с in-house инсталляциями на серверах клиентов и совместимо даже с бэками двухлетней давности. 

• Можно выпускать независимые брендированные версии приложения по запросу клиента. Важно, что это не только повышает статус бренда в глазах сотрудников и партнёров, но и положительно влияет на стабильность и минимизирует проблемы при выходе новых версий: ключевой набор функций нового релиза можно детально перепроверить и решить процессные проблемы ещё до выпуска.

Low-code на службе BDUI

«Первая Форма» занимает лидирующие позиции в рейтинге low-code BPM-систем на российском рынке. Low-code подход обеспечивает существенную гибкость и функциональность нашим приложениям. С ним любые интеграции и настройки процессов можно реализовать проще и без привлечения разработчика платформы (то есть существенно быстрее и дешевле).

В нашем подходе мы активно используем механизм динамического 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

У каждого клиента свои якорные процессы на фоне базовой функциональности платформы. У одних это чек-листы, у других — открытие торговых точек, у третьих — фиксация нарушений и формирование заявок. Но бывают случаи, когда приложение становится центральным элементом IT-инфраструктуры и замыкает на себе все процессы.

Как я уже рассказывал, несколько лет назад к нам пришёл запрос на автоматизацию процессов Международной Гимназии «Сколково» и создание мобильного приложения, которое объединило бы учителей, родителей и различные службы гимназии. Фактически нужно было запустить внутренний мобильный портал, включающий соцсеть для участников и набор внутренних административных сервисов.

Установочная встреча прошла в июле, а уже 1 сентября мы выпустили первую версию приложения SkolCity, в котором оцифровали ключевые процессы Гимназии. Со временем их количество существенно выросло, например, мы добавили:

• чаты для общения родителей и учителей по классам, частых вопросов, консультаций с тьютором и психологом;

• новости и календарь мероприятий;

• информацию по дополнительному образованию и возможность записаться в секции;

• формирование платежных поручений за обучение;

• личный кабинет родителя, где можно управлять профилями детей, заказывать справки, проверять льготы и управлять списком доверенных лиц;

• журнал контроля посещаемости по пропускам и многое другое.

Вскоре подключиться к приложению захотели и другие подразделения «Сколково». Сегодня им пользуются сотрудники Технопарка, арендаторы жилья, центральная диспетчерская, эксперты Фонда и даже его вице-президент. Многие при этом имеют доступ к нескольким функциональным блокам супераппа, так как снимают апартаменты, работают в Технопарке, а их дети обучаются в Гимназии. 

Искать ли альтернативу BDUI или «лучшее — враг хорошего»?

Основные принципы современного IT-подхода — делать быстро, экономично, гибко, с возможностью переиспользовать результаты. Чем больше типовой работы можно сделать без участия разработчика, тем лучше. И в этом плане подход BDUI отлично зарекомендовал себя. Недаром все крупные компании активно развивают свои практики и регулярно делятся друг с другом достижениями на профильных конференциях.

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

В любом случае, важно вовремя переориентировать проект в BDUI-направлении. Мне кажется, что уже не за горами его интенсивное развитие, и потому пора минимизировать подходы уровня «copy/paste» и «monkey job».