REST часто виявляється надмірним у наданні даних (over-fetching) або недостатнім (under-fetching), змушуючи нас писати купу допоміжних ендпоінтів. GraphQL з'явився, щоб вирішити ці проблеми. Сьогодні розберемо, навіщо він потрібен, які проблеми вирішує, а в наступних лекціях перейдемо до його інтеграції зі Spring Boot.
Що таке GraphQL?
Уявіть собі ресторан. Ви відкриваєте меню і замовляєте конкретні страви, точно знаючи, що отримаєте. GraphQL — це як ресторанне меню для вашого API. Ви описуєте, які дані вам потрібні, і сервер повертає саме це (і нічого зайвого). Цю мову запитів розробив Facebook у 2012 році, щоб вирішити проблеми, які вони відчували з REST API під час роботи над мобільними застосунками. Пізніше, у 2015 році, Facebook зробив GraphQL відкритим, і зараз його використовують багато компаній, таких як GitHub, Shopify і Twitter.
GraphQL — це мова запитів для API і час виконання для виконання цих запитів. Його мета — дати розробникам інструмент, за допомогою якого вони зможуть запитувати дані гнучко й ефективно.
Ось кілька ключових характеристик GraphQL:
- Гнучкість запитів. Ви самі вирішуєте, скільки даних і яких саме вам потрібно.
- Сувора типізація. Схема визначає чітку структуру даних, що робить API передбачуваним.
- Єдина точка доступу. Усі запити і мутації йдуть через один URL.
- Підтримка реального часу через підписки (Subscriptions).
Проблеми, які вирішує GraphQL
1. Over-Fetching і Under-Fetching
Уявіть, що ви працюєте з REST API, щоб отримати дані про користувачів. Потрібен тільки їхній email, але REST API повертає повну інформацію про користувача (ім'я, вік, адреса тощо). Це проблема надмірного отримання даних — Over-Fetching.
Тепер уявіть, що вам потрібна інформація про користувачів, включно з їхніми останніми замовленнями. Розробники REST API не додали такий ендпоінт, і доводиться робити два запити: один до /users, інший до /orders. Це проблема недостатності даних — Under-Fetching.
GraphQL вирішує обидві ці проблеми. Ви можете запитувати саме ті дані, які вам потрібні, навіть якщо вони належать різним сутностям.
Приклад запиту в GraphQL:
query {
user(id: 1) {
name
email
orders {
id
total
}
}
}
Цей запит поверне тільки потрібні поля:
{
"data": {
"user": {
"name": "Іван Іванов",
"email": "ivan@example.com",
"orders": [
{"id": 101, "total": 300},
{"id": 102, "total": 150}
]
}
}
}
2. Уніфікація та стандартизація API
У REST API ми часто маємо купу розрізнених ендпоінтів, таких як /users, /orders, /products. У кожного з них свої правила, параметри і відповіді. GraphQL пропонує єдиний ендпоінт (/graphql), через який ми робимо всі запити. Це робить API більш передбачуваним і зручним.
3. Масштабованість
GraphQL дозволяє легко додавати нові можливості в API, не ламавши старі. Схема (Schema) визначає типи даних і їхні зв'язки, і будь-який новий функціонал додається як нова частина схеми без потреби модифікувати існуючі частини.
Основні концепції GraphQL
1. Сувора типізація
GraphQL використовує сувору типізацію для опису даних. Це робиться через схему (Schema), яка визначає всі можливі типи даних і операції, доступні в API. Схема стає контрактом між клієнтом і сервером.
Приклад схеми:
query {
user(id: 1) {
name
email
orders {
id
total
}
}
}
Типи даних у GraphQL:
- Scalar: прості типи на кшталт
Int,Float,String,BooleanіID. - Object: типи з вкладеними полями (наприклад,
User,Order). - Enum: перелічення, наприклад,
Status { ACTIVE, INACTIVE }. - Input: типи для передачі даних у мутації.
2. Запити (Queries)
Запити — це спосіб отримання даних від сервера. Вони аналогічні HTTP GET-запитам у REST API, але з більшою гнучкістю. Клієнт формує запит, вибираючи лише ті поля, які йому потрібні.
Приклад запиту:
query {
user(id: 1) {
name
email
}
}
3. Мутації (Mutations)
Мутації використовуються для змін даних на сервері — аналог POST/PUT/PATCH у REST API. Ви можете створювати, оновлювати або видаляти дані.
Приклад мутації:
mutation {
createUser(name: "Іван Іванов", email: "ivan@example.com") {
id
name
email
}
}
Відповідь:
{
"data": {
"createUser": {
"id": "1",
"name": "Іван Іванов",
"email": "ivan@example.com"
}
}
}
4. Підписки (Subscriptions)
Підписки дозволяють клієнтам отримувати оновлення даних у реальному часі. Наприклад, повідомлення про нові повідомлення в чаті або оновлення статусу замовлення.
Приклад підписки:
subscription {
orderUpdated {
id
status
}
}
Клієнт отримує оновлення, як тільки з'являються нові дані.
Переваги GraphQL порівняно з REST
| Характеристика | GraphQL | REST |
|---|---|---|
| Гнучкість запитів | Клієнт запитує лише потрібні дані | Заздалегідь визначені відповіді ендпоінтів |
| Єдина точка доступу | Один ендпоінт для всіх операцій | Кілька ендпоінтів для різних операцій |
| Типізація | Сувора типізація через схему | Опис даних відсутній |
| Ефективність | Мінімум запитів до сервера | Часто потрібні кілька запитів |
Історія створення GraphQL
Усе почалося у 2012 році, коли Facebook зіткнувся з проблемою продуктивності REST API у своєму мобільному застосунку. Вони зрозуміли, що REST API неефективний для мобільних пристроїв, яким часто були потрібні різні дані залежно від контексту. В результаті GraphQL було створено для вирішення цих проблем. У 2015 році Facebook зробив GraphQL відкритим, і він швидко став популярним у спільноті.
Цікавий факт: GraphQL спочатку розроблявся для внутрішнього використання у Facebook, але потім став драйвером зміни підходу до API в індустрії.
На цьому етапі ми розібралися з основними концепціями GraphQL, його історією і проблемами, які він вирішує. У наступних лекціях ми налаштуємо Spring Boot для роботи з GraphQL і створимо наш перший додаток.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ