Как мы перевернули подход к мобильным интерфейсам с Backend Driven UI

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

В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.

Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.

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

Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.
Читать про формирование UI через бэкенд

Читать: https://habr.com/ru/companies/whoosh/articles/977814/?utm_campaign=977814

@a_cup_of_java | Другие наши каналы