GraphQL: API одним запросом

Экран блога = три запроса

Вспомни проект с блогом: экран поста показывает сам пост, автора и комментарии. С REST это три запроса:

GET /api/posts/42          → пост
GET /api/users/7           → автор
GET /api/posts/42/comments → комментарии

Три сетевых похода вместо одного, а на мобильном интернете каждый — заметная задержка.

Over-fetching: получаем лишнее

GET /api/users/7 возвращает всего пользователя: bio, настройки, дату регистрации... А тебе нужны только имя и аватар. Лишние байты гоняются по сети просто потому, что эндпоинт «один на всех».

Under-fetching: получаем мало

Обратная беда: в ответе поста только authorId, и приходится делать ещё запрос за автором. Данных вечно то больше, то меньше, чем нужно экрану.

N экранов = N эндпоинтов

Мобильному приложению нужен компактный ответ, веб-версии — подробный, новой странице — своя комбинация полей. Бэкенд обрастает эндпоинтами /posts-for-mobile, /posts-with-author... Каждый новый экран — переговоры с бэкенд-командой и новый деплой. 😮‍💨

Идея GraphQL

А что если клиент сам скажет, какие поля и связи ему нужны, — а сервер соберёт ровно такой ответ? Это и есть GraphQL: один эндпоинт POST /graphql, а форму ответа описывает клиент.