Почему я должен использовать интерфейс для ответа типа мутации GraphQL? - PullRequest
Новая
       7

Почему я должен использовать интерфейс для ответа типа мутации GraphQL?

0 голосов
/ 23 февраля 2019

При чтении документации по серверу Apollo рекомендуется использовать интерфейс ответа мутации для мутаций:

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

https://www.apollographql.com/docs/apollo-server/essentials/schema.html

Я понимаю преимущества интерфейсов для вариантов использованиягде у вас есть интерфейс events , а затем у вас есть различные типы событий, такие как концерт, конференция и т. д. Насколько я понимаю, интерфейс позволит вам искать все события с помощью одного запроса, например, возвращая несколькотипы событий.

Меня смущает, почему для ответа на мутацию следует использовать интерфейс, и какие преимущества будут от стандартного типа ответа?

1 Ответ

0 голосов
/ 24 февраля 2019

Как и объединение, интерфейс - это абстрактный тип, который позволяет полю возвращать один из нескольких типов.Из спецификации:

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

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

  • Если у интерфейса есть поле, тип реализации также должен иметь это поле
  • Реализующий тип также должен иметь одинаковые аргументы для любого из этих полей (например, поля могут добавлять дополнительные, но должны по крайней мере реализовывать те же, что и интерфейс)
  • Типы этих обязательныхполя и аргументы должны соответствовать интерфейсу
  • Если тип обязательного поля или интерфейса не равен Null, он также должен быть ненулевым в реализующем типе (хотя обратное неверно)

Создав Интерфейс и реализовав его несколькими типами, вы эффективно создаете сеть безопасности, которая поможет вам обеспечить согласованную структуру для всех связанных типов.Давайте предположим, что мы реализуем некоторые типы ответов, как предложено в документации Apollo, без интерфейса: 

type UpdateUserMutationResponse {
  code: String!
  success: Boolean!
  message: String!
  user: User
}

type UpdatePostMutationResponse {
  code: String!
  success: Boolean!
  message: String
  post: Post
}

На первый взгляд, эти типы определены так, как мы и предполагали - у нас есть поля для code, success и message, а также любые другие поля, относящиеся к этому ответу.Однако у нас есть тип, и мы случайно сделали поле message в UpdatePostMutationResponse равным нулю.Хотя это может быть безвредно, если нам случится пропустить сообщение в нашем преобразователе, оно может остаться незамеченным до некоторого времени (надеюсь, во время QA, но, возможно, в производстве!).

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

Таким образом, даже если мы никогда не используем MutationResponse в качестве возвращаемого типа для полямы все еще можем извлечь выгоду из использования интерфейса.

...