Для чего нужен graphql
Что такое GraphQL: с основ до первых запросов
Это руководство по GraphQL. Из него вы узнаете базовую теорию, а также научитесь писать простые запросы с помощью GraphQL.
Что такое GraphQL: теоретический ликбез
Прежде чем рассматривать GraphQL, давайте уделим внимание исторической базе. Что такое SQL — structured query language или язык структурированных запросов?
SQL — декларативный язык программирования, который применяется для создания, изменения и управления данными в базах данных. Этот язык поддерживает четыре базовых оператора запросов: SELECT, INSERT, UPDATE и DELETE. С помощью SQL мы можем запросить из базы данных (БД) именно то, что нам необходимо.
Прокачивайте свой уровень программирования: На Хекслете есть несколько десятков треков — специальных курсов для опытных программистов, позволяющие повысить уровень компетентности разработчика в разных направлениях.
Например, когда необходимо «достать» из БД всех пользователей с именем Maria, это можно сделать с помощью запроса:
Решить эту задачу с помощью REST можно несколькими способами:
При этом в каждом из вариантов есть свои минусы. Первый подход нельзя масштабировать, так как нет возможности создать endpoint для каждого пользователя. Если мы используем второй подход, повышается нагрузка на сеть, а также появляется необходимость в постобработке на стороне клиента.
А теперь представьте инструмент, который объединяет возможности SQL и REST на стороне клиента. Вы уже догадались, что он называется GraphQL. Этот инструмент берёт идеи, разработанные для манипуляции данными в БД, и использует их в вебе. Поэтому с помощью одного запроса GraphQL можно получить сразу все необходимые данные.
Ниже представлена информация, необходимая для начала работы с GraphQL.
Query: запросы в GraphQL
С помощью запросов GraphQL получает необходимые данные с сервера. Тип запроса Query в GraphQL — аналог GET в REST. Запросы — строки, которые отправляются в теле HTTP POST-запроса.
Примечание — Обратите внимание, все типы запросов в GraphQL отправляются через POST.
Query описывает данные, которые необходимо получить с сервера. Например, с помощью кода ниже можно получить fname и age всех пользователей в базе данных.
В ответ на этот запрос сервер присылает данные в формате JSON. Структура ответа соответствует структуре запроса.
Успешные операции возвращают JSON с ключом «data» и с ключом «error», а неуспешные возвращают JSON с ключом и сообщением об ошибке. Благодаря этому удобно обрабатывать ошибки на стороне клиента.
Mutation: мутации в GraphQL
Mutation — ещё один root types. С его помощью можно добавлять данные в БД. Mutation — аналог POST и PUT в REST. Ниже пример кода.
Здесь создаётся мутация createUser, которая добавляет в БД пользователя с fname Richie и age 22. В ответ на этот запрос сервер присылает JSON с id записи. Ответ выглядит так:
Subscription: подписки в GraphQL
Subscription — третий тип операций в GraphQL. С его помощью клиент слушает изменения в БД в режиме реального времени. Под капотом подписки используют вебсокеты. Пример кода:
С помощью этого запроса можно получать список пользователей с именами и количеством лайков каждый раз, когда оно меняется.
Например, когда пользователь с fname Richie получает лайк, ответ будет таким:
Подобный запрос можно использовать для обновления количества лайков в режиме реального времени в соответствующем интерфейсе, например, в форме с результатами голосования на сайте.
Выше представлены три основных типа запросов в GraphQL. Несмотря на поверхностное знакомство, вы получили достаточно знаний, чтобы начать работать со схемой GraphQL.
Как работать с сервером GraphQL
Рассмотрим ответ на этот вопрос на конкретном примере.
Цель: настроить сервер GraphQL, который отвечает на три типа запросов к БД NoSQL, в которой есть список пользователей с такой структурой:
Также в базе данных есть списки постов, которые опубликовали пользователи.
Для дальнейшей работы понадобится сервер Apollo. Это сервер GraphQL с открытым исходным кодом.
Настройте проект и установите зависимости:
Вы создали пустой проект. Теперь установите GraphQL, Apollo и nodemon для отслеживания изменений в файлах.
Чтобы nodemon работал, добавьте в package.json запись:
База данных
Данные в этом примере поместим в переменную JSON. В реальных проектах данные обычно хранятся в БД. В тестовом проекте данные хранятся в index.js. Вот они:
Теперь можно перейти к работе с сервером GraphQL.
Схема
Работа с сервером GraphQL всегда начинается с разработки схемы (Schema). Она состоит из двух взаимосвязанных объектов: TypeDefs и Resolvers.
Выше были описаны основные типы GraphQL. Чтобы сервер мог с ними работать, эти типы необходимо определить. Объект typeDef определяет список типов, которые доступны в проекте. Код выглядит так:
После определения типов необходимо добавить их логику. Это нужно, чтобы сервер знал, как отвечать на запросы клиента. Эта задача решается с помощью Resolvers.
Resolver
Resolver или распознаватель — функция, которая возвращает данные для определённого поля. Resolver’ы возвращают данные того типа, который определён в схеме. Распознаватели могут быть асинхронными. С их помощью можно получать данные из REST API, базы данных или другого источника.
В примере выше есть шесть функций:
Итак, работа с типами и распознавателями завершена. Теперь можно запустить сервер.
Откройте http://localhost:4000/ в браузере. Благодаря Apollo вы можете полноценно протестировать сервер GraphQL.
Потратили 15 минут на настройку сервера и, вуаля, написали первый запрос. Полная версия кода опубликована здесь.
REST vs. GraphQL
Что делать, если нам нужно найти пользователя, который опубликовал пост с id x? Рассмотрим, как эта задача решается с помощью REST. Вот данные:
Сначала необходимо определить endpoint’ы GET:
Когда необходимо получить данные о пользователе, который опубликовал пост с id 1, запрос выглядит так:
Чтобы получить нужные данные, приходится дважды обращаться к серверу.
Можно попробовать использовать endpoint, который получает только данные из поля fname :
Это решает проблему. Но сложность в том, что вам придётся создавать endpoint для каждого типа информации. Это неудобно.
Давайте посмотрим, как можно решить задачу с помощью GraphQL. Всё, что вам требуется — простой запрос:
Если нужно получить age пользователя, который опубликовал пост с id 1, запрос будет таким:
Поле user в запросе определено в схеме. Поэтому вы можете получать нужную информацию без использования endpoint’ов и повторных обращений к серверу.
Изучайте Node.js на Хекслете Первые курсы в профессии «Node.js-программист» доступны бесплатно. Регистрируйтесь и начинайте учиться.
Заключение
В руководстве рассмотрена базовая информация о GraphQL: краткая теория, типы, отличия от REST. В комментариях можно поделиться впечатлениями о GraphQL и опытом применения этого инструмента.
Адаптированный перевод статьи So, What the Heck is GraphQL by Karthik Kalyanaraman. Мнение автора оригинальной публикации может не совпадать с мнением администрации «Хекслета».
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях.
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Что же такое этот GraphQL?
Вашему вниманию предлагаю перевод статьи Sacha Greif «Что же такое этот GraphQL?»
Если вы такой же, как и я, вы обычно проходите через три этапа, когда узнаёте о новой технологии:
Есть одна хитрость для поддержания благоразумия в эпоху быстроразвивающихся технологий: изучать новые вещи между вторым и третьим этапом, как только интерес задет, но пока технология ещё не распространена повсеместно.
Именно поэтому сейчас самое время узнать, что же такое этот GraphQL, о котором вы повсюду слышите.
Основы
В двух словах, GraphQL это синтаксис, который описывает как запрашивать данные, и, в основном, используется клиентом для загрузки данных с сервера. GraphQL имеет три основные характеристики:
Так с чего же начать изучение GraphQL? Как это выглядит на практике? Как начать его использовать? Читайте дальше чтобы узнать!
Задача
GraphQL был разработан в большом старом Facebook, но даже гораздо более простые приложения могут столкнуться с ограничениями традиционных REST API интерфейсов.
Но затем, при разработке мобильного приложения, оказалось что из-за загрузки дополнительных данных приложение работает медленнее. Так что вам теперь нужно два endpoint, один возвращающий записи с лайками, а другой без них.
Добавим ещё один фактор: оказывается, записи хранятся в базе данных MySQL, а лайки в Redis! Что же теперь делать?!
Экстраполируйте этот сценарий на то множество источников данных и клиентских API, с которыми имеет дело Facebook, и вы поймёте почему старый добрый REST API достиг своего предела.
Решение
Facebook придумал концептуально простое решение: вместо того, чтобы иметь множество «глупых» endpoint, лучше иметь один «умный» endpoint, который будет способен работать со сложными запросами и придавать данным такую форму, какую запрашивает клиент.
Фактически, слой GraphQL находится между клиентом и одним или несколькими источниками данных; он принимает запросы клиентов и возвращает необходимые данные в соответствии с переданными инструкциями. Запутаны? Время метафор!
Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.
GraphQL похож на личного помощника: вы можете передать ему адреса всех трех мест, а затем просто запрашивать то, что вам нужно («принеси мне мою одежду, большую пиццу и два десятка яиц») и ждать их получения.
Другими словами, GraphQL это стандартный язык для разговора с этим волшебным личным помощником.
Согласно Google Images, типичный личный помощник это пришелец с восемью руками
На практике GraphQL API построен на трёх основных строительных блоках: на схеме (schema), запросах (queries) и распознавателях (resolvers).
Запросы (queries)
(query и request одинаково переводится как «запрос». Далее будет подразумеваться query, если не указано иначе – прим. пер.)
Когда вы о чём-то просите вашего персонального помощника, вы выполняете запрос. Это выглядит примерно так:
Как можно заметить, клиенту при формировании запроса не нужно знать откуда поступают данные. Он просто спрашивает о них, а сервер GraphQL заботится об остальном.
Также стоит отметить, что поля запроса могут быть массивами. Например вот общий шаблон запроса списка сообщений:
Поля запроса также могут содержать аргументы. Например, если необходимо отобразить конкретный пост, можно добавить аргумент id к полю post :
Наконец, если нужно сделать аргумент id динамическим, можно определить переменную, а затем использовать её в запросе (обратите внимание, также мы сделали запрос именованным):
Хороший способ попробовать все это на практике – использовать GraphQL API Explorer от GitHub. Например, давайте попробуем выполнить следующий запрос:
GraphQL и автодополнение в действии
Обратите внимание, когда вы вводите имя поля, IDE автоматически предлагает вам возможные имена полей, полученные при помощи GraphQL API. Ловко!
Анатомия запросов GraphQL (англ)
Вы можете узнать больше о запросах GraphQL в отличной статье «Анатомия запросов GraphQL» (англ).
Распознаватели (resolvers)
Даже самый лучший в мире личный помощник не сможет принести ваши вещи из химчистки если вы не дадите ему адрес.
Подобным образом, сервер GraphQL не может знать что делать с входящим запросом, если ему не объяснить при помощи распознавателя (resolver).
Используя распознаватель GraphQL понимает, как и где получить данные, соответствующие запрашиваемому полю. К примеру, распознаватель для поля запись может выглядеть вот так (используя генератор схемы (schema) из набора Apollo GraphQL-Tools):
Мы помещаем наш распознаватель в раздел Query потому что мы хотим получать запись ( post ) в корне ответа. Но также мы можем создать распознаватели для подполей, как например для поля author :
Обратите внимание что ваши распознаватели не ограничены в количестве возвращаемых объектов. К примеру, вы захотите добавить поле commentsCount к объекту Post :
Как было показано выше, вы можете писать любой код внутри распознавателя. Так что вы можете изменять содержимое базы данных; такие распознаватели называют изменяющими (mutation).
Схема (schema)
Все это становится возможным благодаря типизированной схеме данных GraphQL. Цель этой статьи дать скорее краткий обзор, чем исчерпывающее введение, так что в этом разделе не будет подробностей.
Я призываю вас заглянуть в документацию GraphQL (англ), если вы хотите узнать больше.
Часто задаваемые вопросы
Сделаем перерыв, чтобы ответить на несколько общих вопросов.
Эй, вы там, на задних рядах. Да вы. Я вижу, вы хотите что-то спросить. Идите вперед, не стесняйтесь!
Что общего у GraphQL и графовых баз данных?
Ничего общего. На самом деле, GraphQL не имеет ничего общего с графовыми БД типа Neo4j. Часть «Graph» отражает идею получения контента, проходя сквозь граф API, используя поля и подполя; часть «QL» расшифровывается как «query language» – «язык запросов».
Меня полностью устраивает REST, зачем мне переходить на GraphQL?
Если вы не достигли болевых точек REST API, решением которых является GraphQL, то можете не волноваться.
Использование GraphQL поверх REST вероятнее всего не заставит вас производить какие-то сложные изменения в остальном API и ломать накопившийся пользовательский опыт, так что переход не будет вопросом жизни и смерти в любом случае. Так что определенно стоит попробовать GraphQL в небольшой части проекта, если это возможно.
Могу ли я использовать GraphQL без React/Relay/имя_библиотеки?
Конечно! GraphQL это только спецификация, вы можете использовать его с любой библиотекой на любой платформе, используя готовый клиент (к примеру, у Apollo есть клиенты для web, iOS, Angular и другие) или вручную отправляя запросы на сервер GraphQL.
GraphQL был создан Facebook, а я не доверяю Facebook.
Ещё раз, GraphQL является всего лишь спецификацией, это значит что вы можете использовать его не используя ни одной строки кода, написанной Facebook.
Наличие поддержки Facebook это безусловно хороший плюс для экосистемы GraphQL. Но на данный момент сообщество достаточно большое чтобы поддерживать GraphQL, даже если Facebook перестанет его использовать.
Как-то «позволить клиенту просить о тех данных, которые ему нужны» не выглядит безопасным
Так как вы пишете свои распознаватели, вы можете разрешать любые проблемы безопасности на этом уровне.
К примеру, если вы позволите клиенту использовать параметр limit для указания количества документов, которые он запрашивает, вы скорее всего захотите контролировать это число для избежания атак типа «отказ в обслуживании» когда клиент будет запрашивать миллионы документов снова и снова.
Так что же нужно чтобы начать?
На самом деле, необходимо всего два компонента чтобы начать:
Теперь, когда вы понимаете как работает GraphQL, можно поговорить о главных игроках в этой области.
Серверы GraphQL
Первое что вам нужно для работы, это сервер GraphQL. Сам GraphQL это просто спецификация, так что двери открыты для конкурирующих реализаций.
GraphQL-JS (Node)
Это ссылка на оригинальную реализацию спецификации GraphQL. Вы можете использовать её с express-graphql для создания своего сервера API (англ).
GraphQL-Server (Node)
Команда Apollo имеет свою собственную реализацию GraphQL-сервера. Она ещё не настолько полна как оригинал, но очень хорошо документирована, хорошо поддерживается и быстро развивается.
Другие платформы
Клиенты GraphQL
Конечно вы можете работать с API GraphQL напрямую, но специальная клиентская библиотека определённо может сделать вашу жизнь проще.
Relay
Relay это собственный инструментарий Facebook. Он создавался с учётом потребностей Facebook и может быть немного избыточным для большинства пользователей.
Клиент Apollo
Быстро занял своё место новый участник в этой области — Apollo. Типичный клиент состоит из двух частей:
По умолчанию Apollo-client сохраняет данных используя Redux, который сам является достаточно авторитетной библиотекой управления состоянием с богатой экосистемой.
Расширение Apollo для Chrome DevTools
Приложения с открытым исходным кодом
Несмотря на то, что GraphQL это достаточно новая концепция, уже есть некоторые перспективные приложения с открытым исходным кодом, которые используют её.
VulcanJS
Я (автор оригинальной статьи — прим. пер.) являюсь ведущим разработчиком VulcanJS. Я создал его чтобы дать людям возможность попробовать силу стека React/GraphQL без необходимости писать много шаблонного кода. Вы можете воспринимать его как «Rails для современной web-экосистемы» потому что он позволяет создавать CRUD-приложения (клон Instagram например) в течение нескольких часов.
Gatsby
Gatsby это генератор статических сайтов для React, который начиная с версии 1.0 также использует GraphQL. Несмотря на то, что это можно показаться странным сочетанием на первый взгляд, это на самом деле довольно мощная идея. В процессе сборки Gatsby может извлекать данные из нескольких GraphQL API, затем используя их для создания полностью статического клиентского React-приложения.
Другие инструменты для работы с GraphQL
GraphiQL
GraphiQL это очень удобная браузерная IDE для создания и выполнения запросов к endpoint-ам GraphQL.
DataLoader
Из-за вложенной природы запросов GraphQL, один запрос может легко вызывать десятки обращений к базе данных. Для снижения нагрузки вы можете использовать инструменты кеширования наподобие разработанной Facebook библиотеке DataLoader.
Create GraphQL Server
Create GraphQL Server это консольная программа, позволяющая легко и быстро сгенерировать сервер на базе Node, использующий базу данных Mongo.
GraphQL-up
Аналогично Create GraphQL Server, GraphQL-up позволяет быстро создать GraphQL backend, но на базе сервиса Graphcool.
Сервисы GraphQL
Наконец, есть целый ряд компаний, предоставляющих «GraphQL-backend-как-сервис»; они сами позаботятся о серверной части для вас, и это может быть хорошим способом окунуться в экосистему GraphQL.
Graphcool
Гибкая backend-платформа, объединяющая GraphQL и AWS Lambda, имеющая бесплатный тарифный план для разработки.
Scaphold
Другой GraphQL-backend-как-сервис с бесплатным тарифным планом. Он предлагает много функций, подобных Graphcool.
Уже есть немало ресурсов по GraphQL.
(Также предлагайте ресурсы на русском языке в комментариях – прим. пер.)
GraphQL.org (англ)
На официальном сайте GraphQL есть замечательная документация чтобы начать.
LearnGraphQL (англ)
LearnGraphQL это интерактивный курс, созданный в компании Kadira.
LearnApollo (англ)
Хорошее продолжение LearnGraphQL, LearnApollo это бесплатный курс, созданный Graphcool.
Блог Apollo (англ)
Блог Apollo имеет массу подробных хорошо написанных постов о Apollo и GraphQL в целом.
GraphQL Weekly (англ)
Информационная рассылка о GraphQL, курируемая командой Graphcool.
Hashbang Weekly (англ)
Еще одна большая новостная рассылка, которая помимо GraphQL также охватывает React и Meteor.
Freecom (англ)
Серия руководств, описывающая как создать клон Интерком с помощью GraphQL.
Awesome GraphQL (англ)
Довольно исчерпывающий перечень ссылок и ресурсов по GraphQL.
Как же вы можете применить вновь приобретенные знания о GraphQL на практике? Вот несколько рецептов, которые можно попробовать:
Apollo + Graphcool + Next.js
Если вы уже знакомы с Next.js и React, этот пример позволит вам настроить GraphQL endpoint при помощи Graphcool и затем отправлять ей запросы при помощи Apollo.
VulcanJS
Учебник Vulcan (англ) поможет вам создать простой слой данных GraphQL на сервере и на клиенте. Поскольку Vulcan является платформой «все-в-одном», это хороший способ начать работу без каких-либо настроек. Если вам нужна помощь, не стесняйтесь обратиться в наш канал Slack (англ)!
Учебник GraphQL & React
В блоге Chroma есть руководство из шести частей (англ) по созданию приложения React/GraphQL используя компоненто-ориентированный подход к разработке.
Заключение
GraphQL поначалу может показаться сложным, потому что это технология, которая затрагивает многие области современной разработки. Но уделив время чтобы понять основные концепции, я думаю вы поймёте что многое из этого имеет смысл.
Решите ли вы использовать это или нет, я считаю что стоит потратить время чтобы ознакомиться с GraphQL. Все больше и больше компаний и структур начинают использовать его, и он вполне может в течение следующих нескольких лет стать одним из ключевых строительных блоков в веб-разработке.
Согласны? Не согласны? Вопросы? Дайте мне знать, здесь в комментариях.
5 причин, по которым вам не стоит использовать GraphQL
GraphQL неплох, он позволяет вам работать в декларативном стиле, позволяя вам выбирать информацию или операции, которые вам нужны.
Тем не менее, как и любой другой инструмент, это не серебряная пуля.
В этом посте, я расскажу про пять причин, по которым вы не должны использовать GraphQL как альтернативу архитектуре REST:
Конечно, эти ситуации не всегда могут быть применимы к вашему проекту, но важно, что бы вы знали о них и рассматривали (учитывали) последствия.
REST может делать большинство из того, что GraphQL умеет
GraphQL — это альтернатива REST для разработки API, не замена.
Главное преимущество GraphQL — это возможность отправлять запрос, указывающий только ту информацию, которая вам нужна, и получать именно ее.
Но вы так же можете добиться этого используя REST, передавая названия нужных вам полей в URL (реализуя парсинг и логику возврата информации самим):
И это не тяжело реализовать. Существует много библиотек JSON API для многих языков программирования.
Хотите использовать преимущества использования схем и сильной (статической?) типизации для REST?
Существует много библиотек, которые тоже реализуют и поддерживают эту спецификацию.
Хотите использовать язык запросов в REST API?
Суть в том, что существуют альтернативы. Особенно для маленьких приложений, где использование GraphQL может быть перебором.
Конечно, бывают ситуации, при которых будет трудно использовать эти библиотеки, и для таких случаев возможно будет лучше использовать GraphQL, который нативно поддерживать все эти возможности.
Но так же GraphQL может сделать вещи намного более сложнее.
GraphQL сделает некоторые задания более сложнее
Использование GraphQL для маленьких приложений (к примеру тех, которые используют всего несколько полей в одном и тоже же виде, каждый раз) не рекомендуется потому, что оно добавляет сложности из-за таки вещей как:
Что не очень хорошо с точки зрения поддержки.
Но даже если использование GraphQL оправдано, могут возникнуть сложности.
Два примера — обработка ошибок и загрузка файлов.
Используя REST, проверка статуса ответа — это единственный способ узнать, что запрос был успешно выполнен, если была ошибка сервера или если ресурс не был найден.
Но в GraphQL вы получите что-то подобное при возникновении ошибки:
Вам будет необходимо распарсить сообщение, чтобы узнать произошла ли ошибка, и возможно другие ошибки будут иметь слегка разный формат или добавлять некоторые произвольные поля.
Некоторые библиотеки, как Apollo client, помогают с обработкой ошибок, но не так же легко как в REST API.
Насчет загрузки файлов, эта функция не часть спецификации GraphQL, поэтому реализация зависит от вас. Некоторые варианты:
Третий вариант, наверное, предпочтителен. Тем не менее, это означает добавление еще одной зависимости для управления вашим проектом, и это может быть не доступно для всех языков программирования.
Легче использовать веб кеш с REST чем с GraphQl
Я хочу подчеркнуть веб-часть, кеширование на сетевом уровне, потому что вы, безусловно, можете реализовать кеш на уровне базы данных или на уровне клиента с использованием кеша в памяти Apollo Client.
Но кеш, реализованный на уровне HTTP (например, с обратным прокси), который хранит содержимое запроса, может уменьшить объем трафика на сервер или хранить часто доступную информацию в местоположении, близком к клиенту (например, в сети доставки контента).
Поскольку REST API предоставляет множество конечных точек, вы можете легко настроить сетевой кеш для соответствия определенным шаблонам URL, методам HTTP или определенным ресурсам.
В GraphQL существует только одна конечная точка (в большинстве случаев конечная точка HTTP POST), куда отправляются все запросы. Поскольку каждый запрос может быть разным, сложнее использовать этот тип кеширования.
Один из способов уменьшить объем трафика на веб-сервер — это использование постоянных запросов (persisted queries) с помощью persistgraphql.
Этот инструмент назначает идентификаторы для запросов GraphQL, создавая файл JSON, который отображает запросы и идентификаторы. С этой картой клиент отправляет только идентификатор и параметры запроса на сервер, чтобы он мог просто просмотреть его.
Однако это добавляет еще один уровень сложности, и это лишь частично решает проблему.
Проблемы с производительностью с помощью запросов GraphQL
Будучи языком запросов для API, GraphQL предоставляет клиентам возможность выполнять запросы, чтобы получить именно то, что им нужно.
Но что, если клиент отправляет запрос, запрашивающий много полей и ресурсов? Что-то вроде «дайте мне информацию о пользователях, опубликовавших обзор для всех книг этого автора»:
Вы можете просто позволить своим пользователям выполнять любой запрос, который они хотят. GraphQL API должен быть тщательно спроектирован, а не помещен поверх REST API или базы данных.
Для сложных запросов API REST может быть проще спроектировать, потому что у вас может быть несколько конечных точек для конкретных нужд, и для каждого из них вы можете точно настроить конкретные запросы для эффективного извлечения данных.
Это может быть немного противоречивым, потому что многократные сетевые вызовы также могут занять много времени, но если вы не будете осторожны, несколько больших запросов могут положить ваш сервер.
В API GraphQL есть такие инструменты, как Dataloader, которые позволяют вам выполнять пакетные (batch) и кеширующие вызовы базы данных, но в некоторых случаях даже этого будет недостаточно, и единственным решением будет блокировать запросы, вычисляя максимальную стоимость выполнения или глубину запроса. И любое из этих решений будет зависеть от библиотеки, которую вы используете.
Схемы GraphQL могут быть проблемой
Позволяя вам определять схему, GraphQL дает вам много преимуществ, таких как автоматическая проверка и самоанализ.
Но схемы статичны, и ответ, который получат клиенты, зависит от определения схемы и запроса.
Например, вы не можете иметь больше глубины, чем то, что указано в схеме или в запросе, схемы, которые вы можете изменить во время выполнения, или определения динамического типа.
Спецификация GraphQL не охватывает динамические функции, подобные этим, поэтому вам приходится полагаться на хакерские решения или настраиваемые серверные реализации.
Некоторые библиотеки, такие как GraphQL Ruby, имеют механизмы для динамического определения вашей схемы. Это может решить некоторые требования.
С другой стороны, я видел, как люди создают очень общие схемы, чтобы попытаться решить более сложные требования:
Это происходит за счет большинства преимуществ GraphQL.
В этих случаях лучше придерживаться REST.
Заключение
GraphQL — мощный инструмент, и есть много причин выбирать GraphQL вместо REST. Но не забудьте выбрать правильный инструмент для правильной работы.
Аргументы, которые я здесь привел, могут не всегда быть применимы, но стоит учесть их, чтобы узнать, можно ли их решить. Есть все еще варианты использования, когда REST является допустимым подходом.