Статья написана для разработчиков и клиентов. Основные пункты должны внести ясность в работу с промежуточным сервером.
Особенностью заказной разработки мобильных приложений является то, что основной сервер с API обычно предоставляет заказчик. При этом качество API, его готовность, документация и соответствие общепринятым стандартам чаще всего на недостаточном уровне (конечно, стоит отметить, что бывают и счастливые исключения из правил, как раз один такой клиент у нас сейчас есть). Достаточно типичная ситуация, когда интернет-магазин, обслуживаемый изначально системным администратором и программистом (бывает, что обе роли выполняет один и тот же сотрудник), разрастается, и для дальнейшего роста отдел маркетинга принимает решение выпустить мобильное приложение. Ниже список особенностей, с которыми в этом случае придется иметь дело мобильным разработчикам:
- API не дописано — разработчики заказчика загружены текущей работой и не мотивированы сдать его в срок, при том, что у маркетинга планы и сроки запуска мобильного приложения горят;
- API сильно не совпадает со структурой мобильного приложения (данные для экранов приходится дергать с 3-4 методов и обрабатывать локально);
- Нет документации, либо она сильно разрознена и неактуальна;
- Несколько точек входа (разросшаяся инфраструктура находится на нескольких серверах с разными адресами);
- Уже существующее API меняется после апдейтов основного сайта;Отсутствие тестовых серверов;
- Баги (много багов).
И добавим сюда понимание, что со всем этим придется бороться сразу на двух платформах, которые хоть и являются мобильными, часто используют разные архитектурные подходы и, как следствие, разные сроки старта и готовности этапов.
Да, части эти проблем можно избежать, просто согласовав формат API и развернув сервер с тестовыми данными (просто подготовленными json ответами, например). Однако это не решит многих оставшихся, так как об изменении API вы скорее всего узнаете только в момент подключения серверов заказчика.
Все это приводит к увеличению сроков разработки и ,соответственно, стоимости разработки.
Для минимизации всех этих проблем мы предлагаем использовать промежуточный сервер — шину данных.
Приблизительная схема взаимодействия между сервисами в этом случае выглядит так:
Middleware - это, чаще всего, это простой, быстро настраиваемый сервер, не хранящий каких-либо данных, кроме логов. Он позволяет использовать для мобильных приложений простое REST API, строго подогнанное под логику экранов. Бонусом мы имеем возможность разрабатывать приложения со своими наработками по авторизации, обработкам ошибок и прочим мелочам, протестированными и проверенными.
Плюсы такого подхода:
Отсутствуют простои из-за неготовности API заказчика — в худшем случае на шине отдаются тестовые данные;
Упрощается реализация мобильного приложения практически до тонкого клиента;
- Единственная точка входа позволяет упростить архитектуру работы с сетью в МП;
- Возможность выкладывать обновления для сервера шины (меняющую взаимодействие с сервером заказчиком) без обновления МП, в кратчайшие сроки, без модерации со стороны третьих фирм;
- Простота и отсутствие полноценной БД позволяет легко разворачивать любое количество тестовых серверов;
- Удобное логирование всех сетевых ошибок и оповещение о них;
- Изменения в работе API заказчика необходимо вносить только в одном месте — на сервере шины;
- Документация ведется принятым и привычным в компании способом;
- Использование наработок снижает сроки и стоимость разработки.
Все это позволяет снизить сроки и стоимость, напрямую и косвенно, за счет снижения рисков простоя, сложности реализации серверной части и тестирования. Шикарный бонус разработчику — возможность предложить более низкую цену и выиграть конкурс, а заказчику - сэкономить и уменьшить сроки внедрения МП.
Над статьей работали: Пантелеев Алексей, Галактионов Сергей.
Будем рады вашим отзывам о статье.