Тип ответа GraphQL / борьба фрагментов

В общем, если у вас есть поле, которое может разрешаться в один из нескольких типов, вы можете использовать Union. Если эти типы совместно используют одно или несколько полей, вы можете вместо этого использовать интерфейс.

Общий шаблон, который вы видите в схемах, - это идея интерфейса Node. У вас может быть запрос на выборку узла по идентификатору, например:

type Query {
  node(id: ID!): Node
}

interface Node {
  id: ID!
}

type Foo implements Node {
  id: ID!
  foo: String!
}

type Bar implements Node {
  id: ID!
  bar: Int!
}

Здесь Node может быть либо Foo, либо Bar, поэтому, если бы мы записали фрагмент для Node, он мог бы выглядеть примерно так:

fragment NodeFields on Node {
  id # id is part of the interface itself
  ... on Bar {
    bar # fields specific to Bar
  }
  ... on Foo {
    foo # fields specific to Foo
  }
}

Если у вас нет общих полей, вы можете использовать Union вместо этого с тем же эффектом:

union SomeUnion = Foo | Bar

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

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

1. GraphQL уже возвращает результат вашего запроса в виде объекта JSON со свойствами data и errors.
2. Возврат ошибок внутри GraphQL data потребует дополнительной логики для захвата и форматирования ошибок, в отличие от возможности просто выдать ошибку в любом месте и заставить GraphQL обрабатывать отчеты об ошибках за вас.
3. Вы не сможете фиксировать ошибки проверки, поэтому вы потенциально можете столкнуться с ошибками в двух местах - внутри массива errors и внутри data.errors. Это также означает, что ваш клиент должен искать ошибки в двух местах, чтобы правильно обрабатывать ошибки.
4. GraphQL специально разработан, чтобы разрешить частичное разрешение ответа. Это означает, что даже если в некоторых частях ответа возникла ошибка и они не были разрешены, другие могут быть разрешены и возвращены как часть ответа. Это означает, что концепция «успешного» ответа на самом деле не применима в GraphQL. Если вам абсолютно необходимо поле success, было бы гораздо лучше использовать что-то вроде formatResponse, чтобы добавить его к объекту ответа после разрешения запроса.

Это значительно упростит соблюдение соглашений и структурирует вашу схему следующим образом:

type Query {
  login: LoginResponse
}

type LoginResponse {
  token: String
  user: User
}

Фактический ответ по-прежнему будет включать data и errors:

{
  "data": {
    "login": {
      "token": "",
    }
  },
  "errors": []
}

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

Хорошее видео о том, как обрабатывать ошибки (связанные с этим вопросом): https://thewikihow.com/video_-wRXk_QZ3Ko