Давайте обсудим несколько причин, по которым нам нужно реактивное программирование, и что не так с традиционным подходом к API.
1. Поток на модель запроса
- Традиционное программирование обслуживает каждый запрос к серверу, назначая запросу один поток.
- Таким образом, в определенный момент времени максимальное количество одновременных запросов зависит от максимального количества потоков в пуле потоков сервера.
- Это поток для модели запроса.
- Это не значит, что мы можем слепо увеличивать количество потоков в пуле. Больше потоков означает меньше памяти, доступной для обработки.
2. Блокирующий и синхронный API
- Рассмотрим API, у которого есть вызов БД и запрос к другому API.
- В традиционном API, когда выполняется вызов БД/запрос API, он блокирует выполнение текущего API до тех пор, пока не будет получен ответ. Это функция блокировки
- Кроме того, количество времени, затраченное этим традиционным API, равно (время, затраченное на вызов БД + время, затраченное другим API).
- Если мы хотим улучшить время, нам нужно сделать эти вызовы асинхронными/неблокирующими.
3. Что, если бы мы использовали Callbacks/Future, чтобы сделать его асинхронным?
- Обратные вызовы сложны и трудны в обслуживании.
- Completable Future — это API, созданный поверх Future, но он не очень подходит для асинхронного вызова с несколькими элементами в качестве ответа и для обработки исключений.
4. Нет совместимости с обратным давлением
- Рассмотрим случай, когда API отправляет клиенту большой объем данных, и клиент не может обработать их все.
- Здесь было бы полезно, если бы у клиента был способ уведомить сервер о замедлении.
- Это называется совместимостью с обратным давлением.
- Это недоступно в традиционных API.
Так как же должен быть разработан лучший API?
- Асинхронный и неблокирующий.
- Отойдите от модели Thread per request.
- Используйте меньше потоков
- Совместимость с обратным давлением
