# Middleware

![https://www.zaproo.com/uploads/f515911965f54bfda8c1d2a8353fcc51.png](https://www.zaproo.com/uploads/f515911965f54bfda8c1d2a8353fcc51.png)

Связу́ющее програ́ммное обеспе́чение (англ. middleware; также переводится как промежу́точное программное обеспечение, программное обеспечение среднего слоя, подпрогра́ммное обеспечение, межплатфо́рменное программное обеспечение) - широко используемый термин, означающий слой или комплекс технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами. (с) Вики. В данном разделе нас интересует применение в мобильной разработке.

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

* API не дописано - разработчики заказчика загружены текущей работой и не мотивированы сдать его в срок, при том, что у маркетинга планы и сроки запуска мобильного приложения горят;
* API сильно не совпадает со структурой мобильного приложения (данные для экранов приходится дергать с 3-4 методов и обрабатывать локально);
* Нет документации, либо она сильно разрознена и не актуальна;
* Несколько точек входа (разросшаяся инфраструктура находится на нескольких серверах с разными адресами);
* Уже существующее API меняется после апдейтов основного сайта;Отсутствие тестовых серверов;
* Баги (много багов).

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

Для минимизации всех этих проблем предлагается использовать промежуточный сервер - шину данных.

Middleware - чаще всего простой быстро настраиваемый сервер, не хранящий каких-либо данных, кроме логов. Он позволяет использовать для общения мобильных приложений с собой простой REST API, строго подогнанный под логику экранов, а сам уже обращается к целевому API необходимым образом.

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

Плюсы такого подхода:

* Отсутствуют простои из-за неготовности API заказчика - в худшем случае на шине отдаются тестовые данные;
* Упрощается реализация мобильного приложения практически до тонкого клиента;
* Единственная точка входа позволяет упростить архитектуру работы с сетью в МП;
* Возможность выкладывать обновления для сервера шины (меняющую взаимодействие с сервером заказчиком) без обновления МП, в кратчайшие сроки, без модерации со стороны третьих фирм;
* Простота и отсутствие полноценной БД позволяет легко разворачивать любое количество тестовых серверов;
* Удобное логирование всех сетевых ошибок и оповещение о них;
* Изменения в работе API заказчика необходимо вносить только в одном месте - на сервере шины;
* Документация ведется принятым и привычным в компании способом;
* Использование наработок снижает сроки и стоимость разработки.

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

Источники:

* [Middleware, необходимость в мире разработки мобильных приложений](https://www.saratovit.ru/2019/12/27/middleware-mobile-apps/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/mobilnoe-testirovanie/middleware.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.