кстати, судя по видео на канале Apollo на YouTube'е, спикеры как один советуют поменьше required ! полей, нечто аналогичное, кстати, с gRPC API, это объясняется минимизацией ошибок, а также заявляется, что клиент не должен доверять серверу и ему лучше стоит всё проверять, так проще менять схему при необходимости, а ещё если и случится потеря данных, то это будет нечто локальное, а не глобальная ошибка на весь сайт

это я к "3.2. Делайте поля обязательными NonNull, если данные в поле возвращаются при любой ситуации."

Привет.
Есть пользователь, у него есть Name, Surname, Email, Password, etc.
Нужна страница с возможностью изменять каждое поле. По идеи, пользователь может захотеть изменить все или что-то одно.
Вопрос следующий: Желательно писать одну мутацию и посылать поля, которые изменяются, соответственно делать Nullable остальные или писать для каждого поля мутацию? Во втором случае, как я понимаю,  нужно будет посылать oldPassword или токен, чтобы разрешить изменить, хотя, наверное, можно для всего namespace  отправить аргументом.
Вопрос возник из-за прочтения подхода namespace в мутациях.
Спасибо.

Привет, может кто знает, почему когда я использую union тип в query я не могу запросить поля которые есть во всех случаях
например у меня есть

type User1 {
 name: String
 hasChildren: Boolean
}

type User2 {
 name: String
 age: Int
}

union User = User1 | User2

и почему я не могу сделать так

query MyUser {
   User {
     __typename
     name

     ... on User1 {
       hasChildren
     }

     ... on User2 {
       age
     }
   }
 }

своиство name есть во всех случаях, значит оно точно там есть, почему graphql не позволяет такое делать, и может быть есть способ чтобы делать такие запросы было бы можно?

лучше 1й вариант, общая мутация, а поля которые юзер не указал (undefined) не обновлять (многие orm и не обновляют undefined поля). Токен естественно нужно посылать, а иначе как понять кому вообще нужно менять поля

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

Нужноно бэкендеров попросить заюзать Intarface для этого дела, вместо Union

а как именно интерфейс поможет?

в нем указываются общие поля для всех типов

их их можно запросить без фрагментов

Про токен понятно, да. Были сомнения про отдельные мутации. Спасибо за мнение)

если следовать советам спикеров на канале Apollo, то несколько мутаций (отдельно под каждую задачу) лучше одной с кучей опциональных полей, то есть вместо updateUser updateUserName и так далее

Эх, мнения разделились)
После прочтения статьи Павла, сложилось такое же мнение.

я не говорю, что этот вариант именно правильный, я просто вижу, что его этот подход советуют в видео на YouTube канале Apollo

+

Не совсем так. Разделять надо по сущностям. Тут выше был пример у парнишки где при обновлении пользователя обновлялись и роли. Вот такие вещи надо разделять обязательно.

А на каждое поле по мутации спикеры не говорили

Вы к тому, что смысл мутации несет один, правильно понимаю?

Ну у вас есть модель пользователя. Есть внешние связи. Роли это часть пользователя, но не часть модели. Это связанная сущность.

я посмотрел много видеороликов и где-то там оно было) где именно не смогу дать пруф сейчас потому что не особо запоминал, был совет вида "вместо одного mutation с update всех полей на сущность лучше несколько mutations под конкретные задачи" и на экране был какой-то похожий код)

если что, я не поддерживаю именно эту точку зрения (как и не поддерживаю противоположную ей), я пока не определился) it depends, наверное)