Привет, Хабр! Я Артем, раньше был капитаном любительской хоккейной команды, а теперь тимлид продуктовой команды. Раньше у меня стояла цель забить как можно больше голов и выиграть матч, а теперь – зарелизить как можно больше клевых фич и сделать лучшее мобильное приложение для сотрудников.

До перехода в Альфа-Банк работал системным аналитиком, а теперь управляю кросс-функциональной командой, проектирую архитектуру и отвечаю за интеграции корпоративного приложения Alfa People. 

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

До WebView на проекте сложилась довольно классическая история:

• Зоопарк из 23 разных сервисов с недружелюбным интерфейсом: в одном делаешь заявку на отпуск, в другом — бронируешь коворкинг или паркшеринг, в третьем — пишешь в ИТ-поддержку... А хотелось как в лучших домах Лондона топовых приложениях: зашёл и закрыл все задачи в одном пространстве с единым модным-молодежным дизайном.

• Разрозненные бэкенды, которые сложно развивать и интегрировать, если мы хотим сделать единый продукт (а бизнес-заказчик же очень хочет условный Yandex или Госуслуги).

• Денег на разработку не особо много — HR-приложение довольно опосредованно влияет на прибыль компании и точно не принесёт доход здесь и сейчас.

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

Писать приложение на нативе — отдельно iOS, отдельно Android

Плюсы: банк умеет в натив — есть приложение для клиентов (Альфа-Мобайл, Альфа-Инвестиции), есть единая дизайн-система с библиотекой компонентов, с которыми можно разработать крутой UX. 

Минусы: дорогой продакшн, сложно нанять разработчиков (а ты сам готов перейти с бизнесового продукта на внутренний?), ревью через боль и страдание (особенно в App Store).

Выбрать кроссплатформенную разработку: React Native/Flutter

Плюсы: разрабатываем один раз на iOS, Android и на веб, всё ещё классный UX и аргумент-джокер: наш архитектор горел этим вариантом.

Минусы: нет библиотек и экспертизы, редкие дорогие спецы на рынке, ревью в сторах по-прежнему нужно.

Варианты, не добравшиеся до финала: оставить всё как есть, только WEB-приложение/PWA. Ну, и победитель нашего внутреннего соревнования архитектур. Его подробно разберём далее.

Встраивание сервисов в приложение с помощью технологии WebView 

Поговорим об архитектуре приложения. Потренируемся с узнаванием на нашем продукте. Какой из трёх примеров — натив, а где WebView? 

Чтобы начать проект с WebView, мы задействовали несколько команд:

1. Общие ресурсы (архитектор, сисадмин, DevOps).

2. Команда разработчиков iOS и Android – по два человека, Backend-разработчик (у нас исторически .NET) плюс аналитик и тестировщик.

3. Несколько кросс-функциональных команд, которые могут разрабатывать Web-сервисы. Здесь все зависит от того, сколько у вас бэкендов и насколько много может быть сервисов.

Очень интересно, а с чего начинать? 

Что мы первым делом сделали при старте разработки – вы можете так же:

1. Пересобрать команды. Чтобы все сервисы заехали в одно приложение, откажитесь от парадигмы «тут у нас финансы, тут личный кабинет, тут витрина». Теперь у вас общее дело, один клиентский путь.

2. Рескиллить разработчиков. Мы добрали JS-компетенции на курсах Бауманки (нашей программы Alfa Campus тогда ещё не было).

3. Найти спеца, который хорошо умеет во фронтенд. У нас такой эксперт помогает с CI/CD, следит за современными Web-технологиями и внедряет их в продукт.

Как обстоят дела в продуктовых командах с появлением WebView:

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

• Мы сохранили команду, которая существовала ранее, усилили только компетенции фронт-разработчиков.

• Экономим бюджет за счёт универсальности технологий. А также можем делать ротации разработчиков, чтобы они не заскучали.

• Нанимаем больше JS-ров и справляемся в большом продукте с 4 мобильными разработчиками.

А WebView — это же костыль? Потом перепишем нормально?

WebView — это целевая архитектура. Мы проектируем сервисы так, чтобы пользователи не замечали, что они переходят в WebView. Для этого мы используем дизайн-систему, одинаковую для натива и WebView. Но есть нюансы с багами в дизайн-компонентах, когда нарисованное в Figma приходится костылять при разработке. 

Да, конечно, есть сервисы, которые нельзя разработать в WebView, именно для этого на проекте и есть мобильные разработчики. Здесь приведу два поинта: 

1. Есть SDK для встраивания в мобильное приложение. Как пример – спортивные челленджи Alfa Energy. Наше приложение забирает данные из Google Fit и Apple Здоровье, а сотрудники соревнуются в количестве шагов друг с другом. Есть даже статья о том, как мы подключались к Google Fit, пробираясь через тернии к аппрувам от солнечных коллег из Индии Google.

2. Фича уже может быть разработана на нативе в прошлом проекте. Например, флоу аутентификации. Берём и переиспользуем.

Ну и как мне доставлять сервисы без обновления нативного слоя?

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

• Открытие внешних ссылок.

• Скрытие сервисов WebView для нажатия на «Крестик» или стрелки «Назад» после завершения целевого действия в сервисе.

• Переходы на другие сервисы и нативные экраны — здесь нужно предусмотреть универсальные диплинки.

• Загрузка файлов — у нас это прелогин-зона для кандидата, который подгружает кадровые документы для оформления.

• Отображение и скачивание контента. Должна быть предусмотрена возможность скачивать файлы и отображать медиа-контент.

Ну, и пара слов о том, что из себя представляет наш сервисный кластер. Это куберкластер с большим количеством микрофронтендов, которые имеют WEB и мобильную вёрстку.

Мы используем React на фронте, NodeJS (NestJS) в middle-слое, а бэкендом могут выступать различные системы, начиная от SAP и заканчивая самописными бэками.
Такая архитектура позволяет всем командам решать свои специфичные задачи и неважно, на бэке у тебя закостенелый Lotus Notes или же молодёжный NodeJs.

Конечно, у нас настроен CI\CD пайплайн, чтобы быстро выкатывать обновления сервисов как в мобильном приложении, так и в классическом WEB. Если хотите почитать про нашу архитектуру, велкам.

Что в итоге

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

На этом у меня всё, пишите в комментариях, что думаете о WebView, какую технологию для мобильного приложения вы выбрали у себя на проекте, и, как вы считаете, есть ли светлое будущее у PWA-приложений?