Mobile Gateway: как цифровизировать бизнес со сложной инфраструктурой

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

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

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

Mobile Gateway (Middleware-сервер)

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

Что делает Middlware:

1. Собирает всю необходимую информацию со всех сервисов и передает ее приложению единым пакетом.
2. Передает запросы от мобильного приложения нужным сервисам.
3. Кэширует данные сервисов и при отсутствии ответа от одного из них, передает в приложение сохраненные ранее сведения.
4. Дает возможность подключать/отключать сервисы, модернизировать инфраструктуру, не затрагивая мобильное приложение.
5. Обеспечивает безопасность взаимодействия и движения данных внутри системы.

Mobile Gateway (Middleware-сервер или промежуточный сервер)

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

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

Сам по себе промежуточный бекенд старается не хранить никаких данных кроме, возможно, кэша некоторых сервисов, которые к нему подключены. Зачем нужен кэш? Внешний сервис может не отвечать или обрабатывать запрос слишком долго, например, при большой нагрузке. Чтобы не замедлять работу приложения, бэкенд вернет данные от этого сервиса из кэша, а обновит их уже по мере возможности.

Наш опыт

Чаще всего мы сталкиваемся с необходимостью писать middleware-сервер, когда работаем с крупными ритейлерами. Специфика e-commerce такова, что именно в интернет-магазинах существует огромное количество внешних сервисов: управление лояльностью, автоматизация email-маркетинга, управление логистикой, платежами… Список можно продолжать.

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

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

Основная интеграция – с интернет-магазином через API, которое писала ИТ-команда на стороне клиента. Таким образом, мобильное приложение получало основные данные: категории, описания товаров, фотографии, остатки на складе и наличие в магазинах.

Вторая интеграция – с оператором программы лояльности. Фактически мы реализовали ее в самом начале — в приложении для электронной системы лояльности.

Тогда мы продумывали архитектуру для бэкенда и интегрировались с тестовыми и боевыми серверами сервиса. С этой интеграцией было больше всего сложностей.

Исторически у этого сервиса было несколько контуров с API, с разными стеками: API на SOAP, API на привычном Rest. Также сервис работал в трех конфигурациях для разных стран — Россия, Беларусь и Казахстан. И по этой причине нам пришлось делать в приложении три контура - мы писали три разных кода для разных стран.

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

Третья интеграция — с сервисом автоматизации маркетинга. Мы подключали к приложению систему оповещения пользователей и рассылки уведомлений. Здесь тоже не обошлось без доработок. Одновременная отправка пушей всем пользователям создавала высокую нагрузку на сервер. Изначально мы применили, как нам казалось простое решение — отправлять пуш через событие. Когда мобильное устройство подписывается на пуш, получалось, что все получали его одновременно. Чтобы снизить нагрузку, мы отправляем, например, пуши об акциях, распределяя их по времени.

Как подготовить инфраструктуру к разработке middleware?

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

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

2. Расписать бизнес-процессы и работу сервисов в соответствии с ними: какая система какие данные отдает, как получает и обрабатывает.

3. Собрать всю документацию по внешним системам, с которыми будет взаимодействовать приложение: техническая документация, схемы взаимодействия.

4. API к внутренним системам, если мы не меняем инфраструктуру.

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