Уявімо що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод ProductService.getInfo для сутності Product. Задача на фронті зробити логіку додавання товарів в корзину і актуалізація інформації про товари по запиту (наприклад при відкритті корзини нам потрібно оновити інформацію по товарам, які користувач додав собі: наявність, ціни, описи, тощо). В класичному варіанті в нас є два сценарії:
- Сценарій яким йдуть 100% розробників.
Ставиться задача на бекенд на створення окремого методу API, що має повертати колекцію обʼєктів по масиву ідентифікаторів, відповідно це виливається в робочій час бекенд-розробника, тестувальника і фронтенд-розробника, це додаткова точка в коді, яка має бути покрита юніт-тестами, це додатковий сценарій тестування, який має бути зафіксований і доданий до регресійного тестування. І все це треба зробити незважаючи на те, що в нас вже є подібний функціонал, який може повертати один товар по його id. - Альтернативний сценарій яким ніхто не йде
Надсилати окремий запит до API для кожного товару, щоб отримати актуальну інформацію. Тобто, якщо в кошику 10 товарів, нам потрібно зробити 10 HTTP-запитів. Це створює навантаження на мережу і збільшує час очікування для користувача. Тому це неприпустимий варіант.
Але, якщо в нас є можливість відправляти і опрацьовувати batch запити, в нас є альтернатива, яка дуже спростить реалізацію вказаної бізнес-логіки.
Ми можемо використовувати batch запит, щоб об'єднати всі ці запити в один. Ми надсилаємо один запит до API, який містить всі ідентифікатори товарів, і сервер повертає інформацію про всі товари в одній відповіді. Таким чином ми отримуємо:
- Універсальність: Використання batch запитів дозволяє уникнути створення спеціалізованих методів для кожного випадку. Це спрощує API і зменшує кількість необхідного коду.
- Зручність для клієнта: Клієнт може самостійно визначити, які саме запити потрібно об'єднати, що робить API більш гнучким і зручним для використання.
- Зниження складності бекенду: Замість того, щоб писати та підтримувати спеціалізовані методи для різних сценаріїв, можна використовувати універсальний підхід з batch запитами, що спрощує архітектуру бекенду.
Підготовка до використання
Функціональність batch запитів доступна одразу і не вимагає додаткових налаштувань з боку розробника.
Приклад запиту
Розглянемо запит, приклад якого я наводив вище
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"id":"example_1",
"method":"ProductService.getInfo",
"params":{
"productId": 345234
}
},
{
"id":"example_2",
"method":"ProductService.getInfo",
"params":{
"productId": 994234
}
}
]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"id":"example_2",
"result": {
"id": 994234,
"name": "product 2",
"price": 11.99,
"balance": 28
}
},
{
"id":"example_1",
"result": {
"id": 345234,
"name": "product 1",
"price": 99.99,
"balance": 14
}
}
]
ваЖливо
Переваги batch запитів:
- Зменшення кількості мережевих запитів: Замість надсилання декількох HTTP-запитів, що може створювати навантаження на мережу та сервер, використовується лише один запит. Це значно знижує навантаження на мережу та серверні ресурси.
- Час відповіді: RPC Server віддасть результат всіх запитів не зважаючи на їх кількість за стільки часу, скільки необхідно на обробку найдовшого запиту з пакету, тому що обробка всіх запитів відбувається паралельно.
- Зменшення часу затримки: Виконання декількох запитів в одному з'єднанні може знизити загальний час затримки, оскільки зменшується кількість часу, витраченого на встановлення та завершення з'єднань.
- Оптимізація використання ресурсів клієнта та сервера: Оскільки менше запитів обробляється одночасно, знижується навантаження на сервер, що дозволяє йому обробляти більше запитів. Клієнт також використовує менше ресурсів, що може бути критичним для мобільних та обмежених пристроїв.
- Покращена керованість транзакцій: Коли декілька операцій необхідно виконати атомарно (усі або жодна), batch запит дозволяє це зробити легше, оскільки усі операції виконуються в межах одного запиту.