Автор: 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 требует уже другого разговора: о профиле клиентов, кешировании, авторизации, наблюдаемости и цене серверного выполнения.