GraphQL сокращает запрос клиента, но не работу сервера

https://www.youtube-nocookie.com/embed/Xkx5wroOt7o

Автор: Listen IT · YouTube · статья по материалам ролика

---

GraphQL позволяет клиенту описать нужную форму ответа: выбрать поля, пройти по связям между объектами и получить связанные данные одной операцией. Но один сетевой запрос ещё не означает один запрос к базе или автоматически быстрый сервер.

Ролик Listen IT за пятнадцать минут проходит основную механику GraphQL: Query, Mutation и Subscription, поля и аргументы, aliases, fragments, variables и directives. В серверной части появляются схема, typeDefs и resolvers, которые получают данные для запрошенных полей.

Это хороший вводный обзор синтаксиса, но сравнение с REST в нём стоит воспринимать осторожно. GraphQL уменьшает over-fetching и позволяет не собирать экран несколькими клиентскими запросами. При этом сложность не исчезает: она перемещается в схему, resolvers, контроль стоимости запросов, авторизацию и организацию доступа к данным.

Кому смотреть: разработчикам, которые впервые встречают GraphQL и хотят быстро понять, как выглядит запрос и из каких частей состоит серверная схема.

Из этого можно взять в работу: при обсуждении GraphQL отдельно измерять количество HTTP-запросов клиента и количество обращений сервера к хранилищам — это разные показатели.

---

Клиент GraphQL перечисляет поля, которые хочет получить. Arguments уточняют выборку, aliases позволяют запросить одно поле несколько раз под разными именами, а fragments переиспользуют наборы полей. Variables выносят значения из текста операции, а @include и @skip условно меняют состав ответа.

Query используется для чтения, Mutation — для изменения данных, Subscription — для получения обновлений. Доступные операции и типы описываются схемой. Resolvers связывают поля этой схемы с базой, внешним API или другой частью приложения.

На этой границе и находится важное ограничение. Если список из ста объектов запрашивает связанное поле, наивный resolver может выполнить ещё сто обращений к базе. Клиент отправил одну GraphQL-операцию, но сервер получил классическую проблему N+1. Обычно её решают batching и caching, например через DataLoader, а не самим фактом использования GraphQL.

Формулировка «GraphQL лучше REST» поэтому слишком общая. Для API с несколькими клиентами и сильно различающимися экранами гибкая выборка может быть полезна. Для простых ресурсов она способна добавить схему, resolvers, ограничения глубины и сложности запросов без заметной выгоды.

Ролик стоит смотреть как компактное знакомство с языком запросов. Решение о переходе с REST требует уже другого разговора: о профиле клиентов, кешировании, авторизации, наблюдаемости и цене серверного выполнения.