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