Привет, Хабр! Я Артем, раньше был капитаном любительской хоккейной команды, а теперь тимлид продуктовой команды. Раньше у меня стояла цель забить как можно больше голов и выиграть матч, а теперь – зарелизить как можно больше клевых фич и сделать лучшее мобильное приложение для сотрудников.
До перехода в Альфа-Банк работал системным аналитиком, а теперь управляю кросс-функциональной командой, проектирую архитектуру и отвечаю за интеграции корпоративного приложения Alfa People.
Сегодня расскажу, как мы выбирали архитектуру, чтобы быстро релизить, несмотря ни на что. Вы узнаете, как красиво интегрировать разные legacy-бэкенды без толпы разработчиков на проекте, и как продолжать доставлять важный функционал до пользователей, даже если вас удаляют из сторов.
До WebView на проекте сложилась довольно классическая история:
Зоопарк из 23 разных сервисов с недружелюбным интерфейсом: в одном делаешь заявку на отпуск, в другом — бронируешь коворкинг или паркшеринг, в третьем — пишешь в ИТ-поддержку... А хотелось как в
лучших домах Лондонатоповых приложениях: зашёл и закрыл все задачи в одном пространстве с единым модным-молодежным дизайном.Разрозненные бэкенды, которые сложно развивать и интегрировать, если мы хотим сделать единый продукт (а бизнес-заказчик же очень хочет условный Yandex или Госуслуги).
Денег на разработку не особо много — HR-приложение довольно опосредованно влияет на прибыль компании и точно не принесёт доход здесь и сейчас.
После горячих обсуждений, какую же архитектуру для проекта выбрать, в финал вышло несколько технологий.
Писать приложение на нативе — отдельно iOS, отдельно Android
Плюсы: банк умеет в натив — есть приложение для клиентов (Альфа-Мобайл, Альфа-Инвестиции), есть единая дизайн-система с библиотекой компонентов, с которыми можно разработать крутой UX.
Минусы: дорогой продакшн, сложно нанять разработчиков (а ты сам готов перейти с бизнесового продукта на внутренний?), ревью через боль и страдание (особенно в App Store).
Выбрать кроссплатформенную разработку: React Native/Flutter
Плюсы: разрабатываем один раз на iOS, Android и на веб, всё ещё классный UX и аргумент-джокер: наш архитектор горел этим вариантом.
Минусы: нет библиотек и экспертизы, редкие дорогие спецы на рынке, ревью в сторах по-прежнему нужно.
Варианты, не добравшиеся до финала: оставить всё как есть, только WEB-приложение/PWA. Ну, и победитель нашего внутреннего соревнования архитектур. Его подробно разберём далее.
Встраивание сервисов в приложение с помощью технологии WebView
Поговорим об архитектуре приложения. Потренируемся с узнаванием на нашем продукте. Какой из трёх примеров — натив, а где WebView?
Правильный ответ
«Паршкеринг» – это нативная разработка, можно догадаться по нативному лоадеру. А вот сервисы «Мой доход» и «Отпуск» сделаны на WebView. Да-да, на вебвью можно реализовать свайпы и календарь. При этом все три сервиса выполнены в едином стиле.
Чтобы начать проект с WebView, мы задействовали несколько команд:
Общие ресурсы (архитектор, сисадмин, DevOps).
Команда разработчиков iOS и Android – по два человека, Backend-разработчик (у нас исторически .NET) плюс аналитик и тестировщик.
Несколько кросс-функциональных команд, которые могут разрабатывать Web-сервисы. Здесь все зависит от того, сколько у вас бэкендов и насколько много может быть сервисов.
Очень интересно, а с чего начинать?
Что мы первым делом сделали при старте разработки – вы можете так же:
Пересобрать команды. Чтобы все сервисы заехали в одно приложение, откажитесь от парадигмы «тут у нас финансы, тут личный кабинет, тут витрина». Теперь у вас общее дело, один клиентский путь.
Рескиллить разработчиков. Мы добрали JS-компетенции на курсах Бауманки (нашей программы Alfa Campus тогда ещё не было).
Найти спеца, который хорошо умеет во фронтенд. У нас такой эксперт помогает с CI/CD, следит за современными Web-технологиями и внедряет их в продукт.
Как обстоят дела в продуктовых командах с появлением WebView:
Пользователям не надо постоянно обновлять приложение в сторе. Мы забываем историю, когда бежим к дедлайну, выкатываем обновление, а пользователь не ставит его. Не нужно поддерживать обратную совместимость и старые версии.
Мы сохранили команду, которая существовала ранее, усилили только компетенции фронт-разработчиков.
Экономим бюджет за счёт универсальности технологий. А также можем делать ротации разработчиков, чтобы они не заскучали.
Нанимаем больше JS-ров и справляемся в большом продукте с 4 мобильными разработчиками.
А WebView — это же костыль? Потом перепишем нормально?
WebView — это целевая архитектура. Мы проектируем сервисы так, чтобы пользователи не замечали, что они переходят в WebView. Для этого мы используем дизайн-систему, одинаковую для натива и WebView. Но есть нюансы с багами в дизайн-компонентах, когда нарисованное в Figma приходится костылять при разработке.
Да, конечно, есть сервисы, которые нельзя разработать в WebView, именно для этого на проекте и есть мобильные разработчики. Здесь приведу два поинта:
Есть SDK для встраивания в мобильное приложение. Как пример – спортивные челленджи Alfa Energy. Наше приложение забирает данные из Google Fit и Apple Здоровье, а сотрудники соревнуются в количестве шагов друг с другом. Есть даже статья о том, как мы подключались к Google Fit, пробираясь через тернии к аппрувам от солнечных коллег из
ИндииGoogle.Фича уже может быть разработана на нативе в прошлом проекте. Например, флоу аутентификации. Берём и переиспользуем.
Ну и как мне доставлять сервисы без обновления нативного слоя?
Теперь расскажу про лайфхаки для тех, кто хочет выбрать эту технологию для своего продукта. Вам нужно заранее предусмотреть функционал в нативном слое, чтобы можно было делать почти любые фичи на WebView:
Открытие внешних ссылок.
Скрытие сервисов WebView для нажатия на «Крестик» или стрелки «Назад» после завершения целевого действия в сервисе.
Переходы на другие сервисы и нативные экраны — здесь нужно предусмотреть универсальные диплинки.
Загрузка файлов — у нас это прелогин-зона для кандидата, который подгружает кадровые документы для оформления.
Отображение и скачивание контента. Должна быть предусмотрена возможность скачивать файлы и отображать медиа-контент.
Ну, и пара слов о том, что из себя представляет наш сервисный кластер. Это куберкластер с большим количеством микрофронтендов, которые имеют WEB и мобильную вёрстку.
Мы используем React на фронте, NodeJS (NestJS) в middle-слое, а бэкендом могут выступать различные системы, начиная от SAP и заканчивая самописными бэками.
Такая архитектура позволяет всем командам решать свои специфичные задачи и неважно, на бэке у тебя закостенелый Lotus Notes или же молодёжный NodeJs.
Конечно, у нас настроен CI\CD пайплайн, чтобы быстро выкатывать обновления сервисов как в мобильном приложении, так и в классическом WEB. Если хотите почитать про нашу архитектуру, велкам.
Что в итоге
WebView — неплохая технология для встраивания большого количества сервисов в мобильное приложение, особенно если есть риски, что вас могут выпилить из стора и пользователи не смогут обновляться. Чтобы создавать классный UX, я рекомендую заранее предусмотреть все сценарии и сделать доработки в нативном слое, чтобы позже не выдумывать некрасивые костыли.
На этом у меня всё, пишите в комментариях, что думаете о WebView, какую технологию для мобильного приложения вы выбрали у себя на проекте, и, как вы считаете, есть ли светлое будущее у PWA-приложений?
