GraphQL
Язык запросов к API, в котором клиент сам указывает, какие данные ему нужны, и получает ровно их — одним запросом.
GraphQL — язык запросов к API и среда для их выполнения. Компания Facebook создала его в 2012 году для своего мобильного приложения и открыла в 2015-м. Главная идея: клиент сам описывает, какие данные ему нужны, а сервер возвращает ровно их — не больше и не меньше, одним ответом.
Пример запроса
# GraphQL
query {
client(id: 7) {
name
orders(last: 3) {
number
amount
}
}
}
Ответ повторяет форму запроса: имя клиента и три последних заказа с номером и суммой. Если завтра экрану понадобится еще и статус заказа, достаточно добавить поле в запрос — сервер менять не нужно.
Чем отличается от REST
| REST API | GraphQL | |
|---|---|---|
| Адреса | Много ресурсов, у каждого свой адрес | Один адрес для всех запросов |
| Состав ответа | Определяет сервер | Определяет клиент |
| Связанные данные | Часто несколько запросов | Один запрос |
| Кэширование | Просто, средствами HTTP | Сложнее, нужны отдельные решения |
В REST экран профиля может потребовать три запроса — клиент, заказы, адреса — и каждый вернет лишние поля. GraphQL решает обе проблемы: избыточные данные и лишние обращения к серверу. Это особенно заметно в мобильных приложениях на медленной сети.
Из чего состоит
- Схема — строгое описание всех типов данных и связей между ними. По схеме работают подсказки в редакторе и автоматическая проверка запросов.
- Запросы (query) — чтение данных.
- Мутации (mutation) — изменение: создать заказ, изменить адрес.
- Подписки (subscription) — уведомления в реальном времени, например о смене статуса заказа.
Подводные камни
- Нагрузка на базу. Свобода клиента опасна: глубоко вложенный запрос может заставить сервер сделать тысячи обращений к базе (та же проблема N+1, что и в ORM). Поэтому ограничивают глубину и сложность запросов и группируют обращения к данным.
- Кэширование и мониторинг. Все запросы идут на один адрес, и стандартные HTTP-кэши и CDN помогают хуже.
- Права доступа. Проверять их нужно на уровне каждого поля, а не адреса.
Когда выбирать
GraphQL хорош, когда у одного сервера много разных клиентов — веб, мобильные приложения, партнеры — и каждому нужен свой набор данных, или когда данные сильно связаны между собой. Для простых интеграций между системами и публичных API чаще выбирают REST: он проще в кэшировании, отладке и понятен любой команде.