Welcome to Bug or Defect?
youtube - https://www.youtube.com/@BugOrDefect
instagram - https://www.instagram.com/bugordefect_life?igsh=MTFlYzZyMncwZWd4eQ==
Post #719
702
Bug or Defect? Друзі привіт - як ваш день? сподіваюсь ви були в безпеці та з вами і вашими близкими все добре 2 години сну за ніч - 3 чашки кавусі і з 9 працювати) ось відійшов на обід і думаю яж обіцяв - треба написати і як раз народилась нова рубрика - ну шо я маю вам…
Протоколи для QA - GraphQL
Друзі привіт!
Ну що, рухаємося далі по API-протоколах)
Протоколи для QA - GraphQL
І сьогодні у нас GraphQL.
Чесно - це той випадок, коли REST інколи виглядає як велосипед, а GraphQL - як Tesla.
Що я маю вам сказать
GraphQL вирішує одну дуже болючу проблему REST:
або забагато даних, або замало.
У REST ви отримуєте весь payload, хочете ви того чи ні:
риходить 10 полів,
хоча умовно треба два.
А в GraphQL ви самі кажете бекенду що саме тобі потрібно:
І сервер повертає рівно це.
Не менше, не більше.
Тому яка головна суть:
GraphQL = не ресурс, а запит до схеми.
Працює це дуже просто)
У GraphQL є три ключові штуки:
Query - читаємо дані
Mutation - змінюємо дані
Subscription - real-time оновлення (тут вже WebSocket заходить)
Вроді просто але покажу вам приклад краше)
Чим GraphQL відрізняється від REST?
- REST: “Ось готова відповідь, бери все.”
- GraphQL: “Ти сам кажеш, що хочеш.”
Для UI це рай:
1 запит → 1 відповідь → мінімум оверхедів.
Навішо це нам знати як КУА
GraphQL всеж тестується інакше, ніж REST.
Ключові кейси:
валідація схеми (types, required)
null-handling
error extensions
over-fetching / under-fetching
складні поля з залежностями
pagination
versioning без versioning
І дуже важливе:
GraphQL помилки НЕ такі, як REST.
Вони можуть бути:
data + errors одночасно
REST такого не робить.
За часту воно використовується ?
Shopif/GitHub API/Pinterest/Netflix/Slack
Будь-де, де UI потребує багато даних і мало запитів.
Якщо прям дуже коротко
GraphQL = коли дані тобі потрібні точково і швидко.
REST = коли структура проста і зрозуміла.
Обняв 🤗
Друзі привіт!
Ну що, рухаємося далі по API-протоколах)
Протоколи для QA - GraphQL
І сьогодні у нас GraphQL.
Чесно - це той випадок, коли REST інколи виглядає як велосипед, а GraphQL - як Tesla.
Що я маю вам сказать
GraphQL вирішує одну дуже болючу проблему REST:
або забагато даних, або замало.
У REST ви отримуєте весь payload, хочете ви того чи ні:
GET /users/123 → п
риходить 10 полів,
хоча умовно треба два.
А в GraphQL ви самі кажете бекенду що саме тобі потрібно:
query {
user(id: "123") {
name
email
}
}І сервер повертає рівно це.
Не менше, не більше.
Тому яка головна суть:
GraphQL = не ресурс, а запит до схеми.
Працює це дуже просто)
У GraphQL є три ключові штуки:
Query - читаємо дані
Mutation - змінюємо дані
Subscription - real-time оновлення (тут вже WebSocket заходить)
Вроді просто але покажу вам приклад краше)
Запит:
query {
product(id: 42) {
price
currency
}
}
Відповідь:
{
"data": {
"product": {
"price": 200,
"currency": "USD"
}
}
}
Чим GraphQL відрізняється від REST?
- REST: “Ось готова відповідь, бери все.”
- GraphQL: “Ти сам кажеш, що хочеш.”
Для UI це рай:
1 запит → 1 відповідь → мінімум оверхедів.
Навішо це нам знати як КУА
GraphQL всеж тестується інакше, ніж REST.
Ключові кейси:
валідація схеми (types, required)
null-handling
error extensions
over-fetching / under-fetching
складні поля з залежностями
pagination
versioning без versioning
І дуже важливе:
GraphQL помилки НЕ такі, як REST.
Вони можуть бути:
data + errors одночасно
REST такого не робить.
За часту воно використовується ?
Shopif/GitHub API/Pinterest/Netflix/Slack
Будь-де, де UI потребує багато даних і мало запитів.
Якщо прям дуже коротко
GraphQL = коли дані тобі потрібні точково і швидко.
REST = коли структура проста і зрозуміла.
Обняв 🤗
- ❤ 12
- 👍 6
- 🤗 2
- ⚡ 1
