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

Підсумок

• Властивості сторінки (1 змінено, 0 додано, 0 видалено)

Подробиці

Властивості сторінки

Вміст

...	...	@@ -7,26 +7,38 @@
7	7	Batch запити до API — це підхід, який дозволяє об'єднати кілька запитів в один. Замість того, щоб надсилати численні окремі запити до сервера, клієнт може надіслати один запит, який містить кілька операцій. Сервер отримує цей запит, обробляє всі операції та повертає одну загальну відповідь, яка включає результати всіх запитів.
8	8	)))
9	9
10		-Уявімо що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод {{code language="none"}}ProductService.getInfo{{/code}} для сутності {{code language="none"}}Product{{/code}}. Задача на фронті зробити логіку додавання товарів в корзину і актуалізація інформації про товари по запиту (наприклад при відкритті корзини нам потрібно оновити інформацію по товарам, які користувач додав собі: наявність, ціни, описи, тощо). В класичному варіанті в нас є два сценарії:
	10	+= Вступ =
11	11
12		-1. Сценарій яким йдуть 100% розробників.
13		-Ставиться задача на бекенд на створення окремого методу API, що має повертати колекцію обʼєктів по масиву ідентифікаторів, відповідно це виливається в робочій час бекенд-розробника, тестувальника і фронтенд-розробника, це додаткова точка в коді, яка має бути покрита юніт-тестами, це додатковий сценарій тестування, який має бути зафіксований і доданий до регресійного тестування. І все це треба зробити незважаючи на те, що в нас вже є подібний функціонал, який може повертати один товар по його id.
14		-1. Альтернативний сценарій яким ніхто не йде
15		-Надсилати окремий запит до API для кожного товару, щоб отримати актуальну інформацію. Тобто, якщо в кошику 10 товарів, нам потрібно зробити 10 HTTP-запитів. Це створює навантаження на мережу і збільшує час очікування для користувача. Тому це неприпустимий варіант.
	12	+Уявімо що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод {{code language="none"}}ProductService.getInfo{{/code}} для сутності {{code language="none"}}Product{{/code}}. Задача на фронті зробити логіку додавання товарів в кошик і актуалізація інформації про товари по запиту (наприклад при відкритті кошика
16	16
17		-Але, якщо в нас є можливість відправляти і опрацьовувати batch запити, в нас є альтернатива, яка дуже спростить реалізацію вказаної бізнес-логіки.
	14	+Уявімо, що ми розробляємо бекенд API для інтернет-магазину і в нас вже є метод ProductService.getInfo для сутності Product. Задача на фронті полягає у створенні логіки додавання товарів до кошика і актуалізації інформації про товари за запитом (наприклад, при відкритті кошика нам потрібно оновити інформацію про товари, які користувач додав: наявність, ціни, описи, тощо). У класичному варіанті є два сценарії:
18	18
19		-Ми можемо використовувати batch запит, щоб об'єднати всі ці запити в один. Ми надсилаємо один запит до API, який містить всі ідентифікатори товарів, і сервер повертає інформацію про всі товари в одній відповіді. Таким чином ми отримуємо:
	16	+=== Сценарій, яким йдуть 100% розробників ===
20	20
	18	+Ставиться задача на бекенд для створення окремого методу API, який має повертати колекцію об’єктів за масивом ідентифікаторів. Це вимагає робочого часу бекенд-розробника, тестувальника і фронтенд-розробника, оскільки новий метод має бути покритий юніт-тестами, а також додатковими сценаріями для регресійного тестування. Усе це потрібно зробити, незважаючи на те, що у нас вже є метод, який може повертати один товар за його id.
	19	+
	20	+=== Альтернативний сценарій, яким ніхто не йде ===
	21	+
	22	+Надсилати окремий запит до API для кожного товару, щоб отримати актуальну інформацію. Якщо в кошику 10 товарів, це означає 10 HTTP-запитів. Це створює значне навантаження на мережу і збільшує час очікування для користувача, що є неприпустимим варіантом.
	23	+
	24	+=== Альтернатива з використанням batch запитів ===
	25	+
	26	+Якщо ми маємо можливість відправляти і обробляти batch запити, то можемо значно спростити реалізацію бізнес-логіки. Ми можемо використовувати batch запит, щоб об'єднати всі ці запити в один. Ми надсилаємо один запит до API, який містить всі ідентифікатори товарів, і сервер повертає інформацію про всі товари в одній відповіді. Таким чином, ми отримуємо:
	27	+
21	21	1. **Універсальність**: Використання batch запитів дозволяє уникнути створення спеціалізованих методів для кожного випадку. Це спрощує API і зменшує кількість необхідного коду.
22	22	1. **Зручність для клієнта**: Клієнт може самостійно визначити, які саме запити потрібно об'єднати, що робить API більш гнучким і зручним для використання.
23	23	1. **Зниження складності бекенду**: Замість того, щоб писати та підтримувати спеціалізовані методи для різних сценаріїв, можна використовувати універсальний підхід з batch запитами, що спрощує архітектуру бекенду.
24	24
	32	+(% class="box successmessage" %)
	33	+(((
	34	+Такий підхід забезпечує більш ефективне використання ресурсів і покращує продуктивність, зменшуючи навантаження на мережу і сервери, а також поліпшує досвід користувача.
	35	+)))
	36	+
25	25	= Підготовка до використання =
26	26
27	27	Функціональність batch запитів доступна одразу і не вимагає додаткових налаштувань з боку розробника.
28	28
29		-= Приклад запиту =
	41	+= Приклад =
30	30
31	31	Розглянемо запит, приклад якого я наводив вище
32	32
...	...	@@ -86,11 +86,23 @@
86	86	)))
87	87	)))
88	88
	101	+= Послідовність запитів =
	102	+
	103	+Послідовність наповнення batch не має значення, бо на RPC сервері всі запити виконуються паралельно і ви отримаєте відповідь із швидкістю найдовшого запиту з переліку.
	104	+
	105	+Якщо в якомусь запиті з переліку відбудеться помилка, це ніяк не впливає на опрацювання інших запитів з переліку.
	106	+
	107	+= Залежні запити =
	108	+
89	89	(% class="wikigeneratedid" %)
90		-ваЖливо
	110	+Механізм batch запитів дозволяє створювати залежні запити. Це такий запит, один або кілька параметрів якого, залежать від відповіді з іншого запиту в переліку.
91	91
	112	+(% class="wikigeneratedid" %)
	113	+Наприклад нам потрібно о
	114	+
92	92	= Переваги batch запитів: =
93	93
	117	+1. **Спрощення бекенду:** Замість того, щоб кожен раз реалізовувати специфічну логіку на боці бекенду, можна винести це на рівень побудови клієнтських запитів.
94	94	1. **Зменшення кількості мережевих запитів**: Замість надсилання декількох HTTP-запитів, що може створювати навантаження на мережу та сервер, використовується лише один запит. Це значно знижує навантаження на мережу та серверні ресурси.
95	95	1. **Час відповіді**: RPC Server віддасть результат всіх запитів не зважаючи на їх кількість за стільки часу, скільки необхідно на обробку найдовшого запиту з пакету, тому що обробка всіх запитів відбувається паралельно.
96	96	1. **Зменшення часу затримки**: Виконання декількох запитів в одному з'єднанні може знизити загальний час затримки, оскільки зменшується кількість часу, витраченого на встановлення та завершення з'єднань.