Зміни в документі Batch запити

Остання зміна 2024/05/16 18:58 автором Ashterix
Від версії 3.3
редаговано Ashterix
дата 2024/05/16 15:46
Змінити коментар: Немає коментарів для цієї версії
До версії 3.4
редаговано Ashterix
дата 2024/05/16 16:54
Змінити коментар: Немає коментарів для цієї версії

Підсумок

Подробиці

Властивості сторінки
Вміст
... ... @@ -2,26 +2,26 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 += Вступ =
6 +
5 5  (% class="box infomessage" %)
6 6  (((
7 7  Batch запити до API — це підхід, який дозволяє об'єднати кілька запитів в один. Замість того, щоб надсилати численні окремі запити до сервера, клієнт може надіслати один запит, який містить кілька операцій. Сервер отримує цей запит, обробляє всі операції та повертає одну загальну відповідь, яка включає результати всіх запитів.
8 8  )))
9 9  
10 -= Вступ =
11 -
12 12  Уявімо що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод {{code language="none"}}ProductService.getInfo{{/code}} для сутності {{code language="none"}}Product{{/code}}. Задача на фронті зробити логіку додавання товарів в кошик і актуалізація інформації про товари по запиту (наприклад при відкритті кошика
13 13  
14 14  Уявімо, що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод ProductService.getInfo для сутності Product. Задача на фронті полягає у створенні логіки додавання товарів до кошика і актуалізації інформації про товари за запитом (наприклад, при відкритті кошика нам потрібно оновити інформацію про товари, які користувач додав: наявність, ціни, описи, тощо). У класичному варіанті є два сценарії:
15 15  
16 -=== Сценарій, яким йдуть 100% розробників ===
16 +== Сценарій, яким йдуть 100% розробників ==
17 17  
18 18  Ставиться задача на бекенд для створення окремого методу API, який має повертати колекцію об’єктів за масивом ідентифікаторів. Це вимагає робочого часу бекенд-розробника, тестувальника і фронтенд-розробника, оскільки новий метод має бути покритий юніт-тестами, а також додатковими сценаріями для регресійного тестування. Усе це потрібно зробити, незважаючи на те, що у нас вже є метод, який може повертати один товар за його id.
19 19  
20 -=== Альтернативний сценарій, яким ніхто не йде ===
20 +== Сценарій, яким ніхто не йде ==
21 21  
22 22  Надсилати окремий запит до API для кожного товару, щоб отримати актуальну інформацію. Якщо в кошику 10 товарів, це означає 10 HTTP-запитів. Це створює значне навантаження на мережу і збільшує час очікування для користувача, що є неприпустимим варіантом.
23 23  
24 -=== Альтернатива з використанням batch запитів ===
24 +== Альтернатива з використанням batch запитів ==
25 25  
26 26  Якщо ми маємо можливість відправляти і обробляти batch запити, то можемо значно спростити реалізацію бізнес-логіки. Ми можемо використовувати batch запит, щоб об'єднати всі ці запити в один. Ми надсилаємо один запит до API, який містить всі ідентифікатори товарів, і сервер повертає інформацію про всі товари в одній відповіді. Таким чином, ми отримуємо:
27 27  
... ... @@ -34,10 +34,11 @@
34 34  Такий підхід забезпечує більш ефективне використання ресурсів і покращує продуктивність, зменшуючи навантаження на мережу і сервери, а також поліпшує досвід користувача.
35 35  )))
36 36  
37 -= Підготовка до використання =
37 +(% class="box warningmessage" %)
38 +(((
39 +Звісно, що у високонавантажених системах подібниій сценарій буде не ефективним, прото існують інші варіанти оптимізацій, які ми розглянемо в інших статтях.
40 +)))
38 38  
39 -Функціональність batch запитів доступна одразу і не вимагає додаткових налаштувань з боку розробника.
40 -
41 41  = Приклад =
42 42  
43 43  Розглянемо запит, приклад якого я наводив вище
... ... @@ -98,6 +98,21 @@
98 98  )))
99 99  )))
100 100  
102 +
103 +
104 +== Переваги batch запитів: ==
105 +
106 +1. **Спрощення бекенду:** Замість того, щоб кожен раз реалізовувати специфічну логіку на боці бекенду, можна винести це на рівень побудови клієнтських запитів.
107 +1. **Зменшення кількості мережевих запитів**: Замість надсилання декількох HTTP-запитів, що може створювати навантаження на мережу та сервер, використовується лише один запит. Це значно знижує навантаження на мережу та серверні ресурси.
108 +1. **Час відповіді**: RPC Server віддасть результат всіх запитів не зважаючи на їх кількість за стільки часу, скільки необхідно на обробку найдовшого запиту з пакету, тому що обробка всіх запитів відбувається паралельно.
109 +1. **Зменшення часу затримки**: Виконання декількох запитів в одному з'єднанні може знизити загальний час затримки, оскільки зменшується кількість часу, витраченого на встановлення та завершення з'єднань.
110 +1. **Оптимізація використання ресурсів клієнта та сервера**: Оскільки менше запитів обробляється одночасно, знижується навантаження на сервер, що дозволяє йому обробляти більше запитів. Клієнт також використовує менше ресурсів, що може бути критичним для мобільних та обмежених пристроїв.
111 +1. **Покращена керованість транзакцій**: Коли декілька операцій необхідно виконати атомарно (усі або жодна), batch запит дозволяє це зробити легше, оскільки усі операції виконуються в межах одного запиту.
112 +
113 += Підготовка до використання =
114 +
115 +Функціональність batch запитів доступна одразу і не вимагає додаткових налаштувань з боку розробника.
116 +
101 101  = Послідовність запитів =
102 102  
103 103  Послідовність наповнення batch не має значення, бо на RPC сервері всі запити виконуються паралельно і ви отримаєте відповідь із швидкістю найдовшого запиту з переліку.
... ... @@ -104,19 +104,85 @@
104 104  
105 105  Якщо в якомусь запиті з переліку відбудеться помилка, це ніяк не впливає на опрацювання інших запитів з переліку.
106 106  
123 +
107 107  = Залежні запити =
108 108  
109 -(% class="wikigeneratedid" %)
126 +(% class="box infomessage" %)
127 +(((
110 110  Механізм batch запитів дозволяє створювати залежні запити. Це такий запит, один або кілька параметрів якого, залежать від відповіді з іншого запиту в переліку.
129 +)))
111 111  
112 112  (% class="wikigeneratedid" %)
113 -Наприклад нам потрібно о
132 +Уявімо, що нам з фронтенда потрібно отримати email адресу користувача за його ідентифікатором, а потім відправити йому повідомлення на цю адресу. В нас вже існують методи {{code language="none"}}UserService.getInfo{{/code}} та {{code language="none"}}Messenger.sendEmail{{/code}}. В класичному сценарії це буде або два запити або необхідно створити на бекенді окремий метод, який буде відправляти email по id користувача.
114 114  
115 -= Переваги batch запитів: =
134 +(% class="wikigeneratedid" %)
135 +Використовуючи бібліотеку {{code language="none"}}JsonRpcBundle{{/code}} від UFO-Tech у вас є можливість створювати batch запити, де перший один запит може ставати залежним від іншого і буде отримувати його відповідь для запуску. В контексті прикладу ми в одному запиті отримаємо інформацію про користувача, а другий запит використує отриманий емейл для відправки повідомлення.
116 116  
117 -1. **Спрощення бекенду:** Замість того, щоб кожен раз реалізовувати специфічну логіку на боці бекенду, можна винести це на рівень побудови клієнтських запитів.
118 -1. **Зменшення кількості мережевих запитів**: Замість надсилання декількох HTTP-запитів, що може створювати навантаження на мережу та сервер, використовується лише один запит. Це значно знижує навантаження на мережу та серверні ресурси.
119 -1. **Час відповіді**: RPC Server віддасть результат всіх запитів не зважаючи на їх кількість за стільки часу, скільки необхідно на обробку найдовшого запиту з пакету, тому що обробка всіх запитів відбувається паралельно.
120 -1. **Зменшення часу затримки**: Виконання декількох запитів в одному з'єднанні може знизити загальний час затримки, оскільки зменшується кількість часу, витраченого на встановлення та завершення з'єднань.
121 -1. **Оптимізація використання ресурсів клієнта та сервера**: Оскільки менше запитів обробляється одночасно, знижується навантаження на сервер, що дозволяє йому обробляти більше запитів. Клієнт також використовує менше ресурсів, що може бути критичним для мобільних та обмежених пристроїв.
122 -1. **Покращена керованість транзакцій**: Коли декілька операцій необхідно виконати атомарно (усі або жодна), batch запит дозволяє це зробити легше, оскільки усі операції виконуються в межах одного запиту.
137 +(% class="row" %)
138 +(((
139 +(% class="col-xs-12 col-sm-6" %)
140 +(((
141 +{{code language="json" layout="LINENUMBERS" title="Request"}}
142 +[
143 + {
144 + "id":"example_1",
145 + "method":"UserService.getInfo",
146 + "params":{
147 + "userId": 141
148 + }
149 + },
150 + {
151 + "id":"example_2",
152 + "method":"Messenger.sendEmail",
153 + "params":{
154 + "email": "@FROM:example_1(email)",
155 + "subject": "Welcome!",
156 + "message": "Thank you for joining our service!"
157 + }
158 + }
159 +]
160 +{{/code}}
161 +)))
162 +
163 +(% class="col-xs-12 col-sm-6" %)
164 +(((
165 +{{code language="json" layout="LINENUMBERS" title="Response"}}
166 +[
167 + {
168 + "id":"example_1",
169 + "result": {
170 + "id": 141,
171 + "name": "John",
172 + "email": "john.dou@example.com",
173 + "status": 1
174 + }
175 + },
176 + {
177 + "id":"example_2",
178 + "result": "Email for 'john.dou@example.com' sent"
179 + }
180 +]
181 +{{/code}}
182 +)))
183 +)))
184 +
185 +У цьому прикладі:
186 +
187 +1. Перший запит отримує інформацію про користувача з id 141, включаючи його емейл.
188 +1. Другий запит відправляє лист на отриманий емейл, використовуючи дані з першого запиту.
189 +
190 +(% class="box infomessage" %)
191 +(((
192 +**Послідовність запитів не має значення! **RPC Server сам визначає наявність залежність запитів і ставить їх в чергу в потрібній послідовності.
193 +)))
194 +
195 +(% class="box warningmessage" %)
196 +(((
197 +Залежні запити виконуються послідовно, тож відповідь на batch запит повернеться після завершення залежних запитів.
198 +)))
199 +
200 +== Переваги використання залежних запитів: ==
201 +
202 +1. **Зручність і ефективність**: Залежні запити дозволяють виконувати складні операції з мінімальними зусиллями, забезпечуючи правильну послідовність виконання запитів.
203 +1. **Зменшення кількості мережевих запитів**: Усі запити об'єднуються в один, що знижує навантаження на мережу.
204 +1. **Гнучкість**: Можливість створювати складні сценарії запитів без необхідності додаткових налаштувань чи змін на бекенді.