Почему существуют «два имени» для каждого запроса / мутации GraphQL? - PullRequest
Новая
       7

Почему существуют «два имени» для каждого запроса / мутации GraphQL?

1 голос
/ 20 марта 2019

Я изучаю GraphQL, и один из основных моментов меня озадачил.Я знаю, что есть простое объяснение, но я не могу его найти.В частности, из документации Apollo (https://www.apollographql.com/docs/apollo-server/essentials/data.html#operation):

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

query HomeBookListing {   
     getBooks {
     title   
     } 
 }

Если HomeBookListing - это имя запроса, то, что тогда будет getBooks? Имя резольвера?

Аналогично, когда вы передаете переменные в запрос, почему существуют "два уровня" параметров, как это 

mutation HomeQuickAddBook($title: String, $author: String = "Anonymous") {
  addBook(title: $title, author: $author) {
    title
  }
}

Итак, $title: String, $author: String = "Anonymous" переменные, передаваемые в запрос, и title: $title, author: $author переменные, передаваемые в распознаватель?

Конечно, я могу запомнить шаблон, но мне интересно понять, концептуально, что здесь делают разные частиЛюбое понимание высоко ценится!

1 Ответ

3 голосов
/ 20 марта 2019

Возможно, вам будет полезно просмотреть спецификацию , но ниже приведено несколько более короткое объяснение:

Что такое операция?

Есть три операции вGraphQL (query, mutation и subscription).Как правило, запрос GraphQL состоит только из одной из этих трех операций и формирует корень запроса или точку входа в остальную часть схемы.

С каждой операцией связан отдельный тип объекта,По соглашению эти типы называются Query, Mutation и Subscription, но их именование функционально не имеет отношения к вашей схеме.Кроме их связи с определенной операцией, в этих типах объектов нет ничего особенного - у каждого есть name, description и fields, как и у любого другого типа объекта в вашей схеме.В совокупности мы называем эти три типа корневыми типами операций .

В вашем примере корневой тип query имеет поле , называемое getBooks.Это поле разрешается в соответствии с теми же правилами, что и любое другое поле в вашей схеме.Единственная особенность этого поля в том, что оно находится в корне - нет никакого родительского поля, которое было бы разрешено до него.

Имена операций являются необязательными, поскольку они не влияют на данные, возвращаемые сервером -- они обычно используются для целей отладки (хотя некоторые клиенты и инструменты используют их для предоставления других функций, поэтому всегда полезно иметь их).Однако необходимо указать хотя бы одно имя поля для вашего корневого типа операции, иначе ваша операция на самом деле ничего не сделает (т.е. запросит данные у сервера).Опять же, эти поля являются вашей точкой входа в остальную часть схемы и отправной точкой для вашего графа данных.

Хорошо, а как насчет переменных?

Согласно спецификации:

Переменные должны быть определены в верхней части операции и находятся в области действия во время выполнения этой операции.

Хотя мы не инициализируем переменную внутри документа значениемнам нужно определить его, сообщив GraphQL, какой это тип переменной.Это позволяет GraphQL затем проверять использование ваших переменных по всему документу.Например, если вы определите переменную как String, а затем попытаетесь использовать ее в поле ввода, равном Int, проверка завершится неудачно, и ваш запрос будет взорван еще до того, как он будет выполнен.

Переменные всегда определяются как часть определения операции - они могут использоваться в любом месте документа, хотя и несколько раз.Таким образом, здесь нет «двух уровней параметров» - одна строка - просто определение, другая - использование.

Слово о семантике

Даже если у нас есть спецификация,Язык вокруг GraphQL эволюционировал после обозначенных в нем терминов.Термин «запрос» имеет несколько значений, с которыми вы можете столкнуться при просмотре различных документов и статей.Помните об этих определениях, чтобы не запутаться:

  • По соглашению мы называем тип корневой операции, связанный с операцией query, типом Query *
  • Неформальнополя в этом Query (то есть getBooks), которые часто называют «запросами» вашей схемы (точно так же, как поля типа Mutation часто называют «мутациями» вашей схемы.
  • Полная строка запроса, которую мы отправляем на сервер, которая включает всю операцию и любые соответствующие фрагменты официально называется документом . Однако,мы часто называем запрос запросом к серверу . Это приводит к тому, что сам документ часто называют запросом, независимо от того, содержит ли операция на самом деле query или другую операцию, например mutation.
...