Batch запити

Версія 3.4 додана 2024/05/16 16:54 автором Ashterix
Зміст

Вступ

Batch запити до API — це підхід, який дозволяє об'єднати кілька запитів в один. Замість того, щоб надсилати численні окремі запити до сервера, клієнт може надіслати один запит, який містить кілька операцій. Сервер отримує цей запит, обробляє всі операції та повертає одну загальну відповідь, яка включає результати всіх запитів.

Уявімо що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод ProductService.getInfo для сутності Product. Задача на фронті зробити логіку додавання товарів в кошик і актуалізація інформації про товари по запиту (наприклад при відкритті кошика

Уявімо, що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод ProductService.getInfo для сутності Product. Задача на фронті полягає у створенні логіки додавання товарів до кошика і актуалізації інформації про товари за запитом (наприклад, при відкритті кошика нам потрібно оновити інформацію про товари, які користувач додав: наявність, ціни, описи, тощо). У класичному варіанті є два сценарії:

Сценарій, яким йдуть 100% розробників

Ставиться задача на бекенд для створення окремого методу API, який має повертати колекцію об’єктів за масивом ідентифікаторів. Це вимагає робочого часу бекенд-розробника, тестувальника і фронтенд-розробника, оскільки новий метод має бути покритий юніт-тестами, а також додатковими сценаріями для регресійного тестування. Усе це потрібно зробити, незважаючи на те, що у нас вже є метод, який може повертати один товар за його id.

Сценарій, яким ніхто не йде

Надсилати окремий запит до API для кожного товару, щоб отримати актуальну інформацію. Якщо в кошику 10 товарів, це означає 10 HTTP-запитів. Це створює значне навантаження на мережу і збільшує час очікування для користувача, що є неприпустимим варіантом.

Альтернатива з використанням batch запитів

Якщо ми маємо можливість відправляти і обробляти batch запити, то можемо значно спростити реалізацію бізнес-логіки. Ми можемо використовувати batch запит, щоб об'єднати всі ці запити в один. Ми надсилаємо один запит до API, який містить всі ідентифікатори товарів, і сервер повертає інформацію про всі товари в одній відповіді. Таким чином, ми отримуємо:

  1. Універсальність: Використання batch запитів дозволяє уникнути створення спеціалізованих методів для кожного випадку. Це спрощує API і зменшує кількість необхідного коду.
  2. Зручність для клієнта: Клієнт може самостійно визначити, які саме запити потрібно об'єднати, що робить API більш гнучким і зручним для використання.
  3. Зниження складності бекенду: Замість того, щоб писати та підтримувати спеціалізовані методи для різних сценаріїв, можна використовувати універсальний підхід з batch запитами, що спрощує архітектуру бекенду.

Такий підхід забезпечує більш ефективне використання ресурсів і покращує продуктивність, зменшуючи навантаження на мережу і сервери, а також поліпшує досвід користувача.

Звісно, що у високонавантажених системах подібниій сценарій буде не ефективним, прото існують інші варіанти оптимізацій, які ми розглянемо в інших статтях.

Приклад

Розглянемо запит, приклад якого я наводив вище

Request
1
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
      }
   }
]

Важливо!!! Завжди вказуйте в butch запитах унікальні ід запиту, бо відповіді можуть повертатися в іншому порядку.

Response
1
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 запитів:

  1. Спрощення бекенду: Замість того, щоб кожен раз реалізовувати специфічну логіку на боці бекенду, можна винести це на рівень побудови клієнтських запитів.
  2. Зменшення кількості мережевих запитів: Замість надсилання декількох HTTP-запитів, що може створювати навантаження на мережу та сервер, використовується лише один запит. Це значно знижує навантаження на мережу та серверні ресурси.
  3. Час відповіді: RPC Server віддасть результат всіх запитів не зважаючи на їх кількість за стільки часу, скільки необхідно на обробку найдовшого запиту з пакету, тому що обробка всіх запитів відбувається паралельно.
  4. Зменшення часу затримки: Виконання декількох запитів в одному з'єднанні може знизити загальний час затримки, оскільки зменшується кількість часу, витраченого на встановлення та завершення з'єднань.
  5. Оптимізація використання ресурсів клієнта та сервера: Оскільки менше запитів обробляється одночасно, знижується навантаження на сервер, що дозволяє йому обробляти більше запитів. Клієнт також використовує менше ресурсів, що може бути критичним для мобільних та обмежених пристроїв.
  6. Покращена керованість транзакцій: Коли декілька операцій необхідно виконати атомарно (усі або жодна), batch запит дозволяє це зробити легше, оскільки усі операції виконуються в межах одного запиту.

Підготовка до використання

Функціональність batch запитів доступна одразу і не вимагає додаткових налаштувань з боку розробника.

Послідовність запитів

Послідовність наповнення batch не має значення, бо на RPC сервері всі запити виконуються паралельно і ви отримаєте відповідь із швидкістю найдовшого запиту з переліку.

Якщо в якомусь запиті з переліку відбудеться помилка, це ніяк не впливає на опрацювання інших запитів з переліку.

Залежні запити

Механізм batch запитів дозволяє створювати залежні запити. Це такий запит, один або кілька параметрів якого, залежать від відповіді з іншого запиту в переліку.

Уявімо, що нам з фронтенда потрібно отримати email адресу користувача за його ідентифікатором, а потім відправити йому повідомлення на цю адресу. В нас вже існують методи UserService.getInfo та Messenger.sendEmail. В класичному сценарії це буде або два запити або необхідно створити на бекенді окремий метод, який буде відправляти email по id користувача.

Використовуючи бібліотеку JsonRpcBundle від UFO-Tech у вас є можливість створювати batch запити, де перший один запит може ставати залежним від іншого і буде отримувати його відповідь для запуску. В контексті прикладу ми в одному запиті отримаємо інформацію про користувача, а другий запит використує отриманий емейл для відправки повідомлення.

Request
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[
   {
     "id":"example_1",
     "method":"UserService.getInfo",
     "params":{
        "userId": 141
      }
   },
   {
     "id":"example_2",
     "method":"Messenger.sendEmail",
     "params":{
        "email": "@FROM:example_1(email)",
        "subject": "Welcome!",
        "message": "Thank you for joining our service!"
      }
   }
]
Response
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[
   {
     "id":"example_1",
     "result": {
        "id": 141,
        "name": "John",
        "email": "john.dou@example.com",
        "status": 1
      }
   },
   {
     "id":"example_2",
     "result": "Email for 'john.dou@example.com' sent"
   }
]

У цьому прикладі:

  1. Перший запит отримує інформацію про користувача з id 141, включаючи його емейл.
  2. Другий запит відправляє лист на отриманий емейл, використовуючи дані з першого запиту.

Послідовність запитів не має значення! RPC Server сам визначає наявність залежність запитів і ставить їх в чергу в потрібній послідовності.

Залежні запити виконуються послідовно, тож відповідь на batch запит повернеться після завершення залежних запитів.

Переваги використання залежних запитів:

  1. Зручність і ефективність: Залежні запити дозволяють виконувати складні операції з мінімальними зусиллями, забезпечуючи правильну послідовність виконання запитів.
  2. Зменшення кількості мережевих запитів: Усі запити об'єднуються в один, що знижує навантаження на мережу.
  3. Гнучкість: Можливість створювати складні сценарії запитів без необхідності додаткових налаштувань чи змін на бекенді.