фронты любят разделение мутаций, потому что удобно делать атомарные мутации – одно действие в интерфейсе соответствует одной мутации

Короче, все объекты, что возвращаются с сервера имеют идентификатор, вида __typename + ID

так что вообще пофигу где они были получены, в следствии квери или мутаций

и как изменится их "любовь", если убрать кейворд "mutation" у запроса?)))

Потому что сейчас получается просто невероятное количество копипасты кода, который переиспольузется и в мутациях, и в квери (+ в аргументах)

В реальной жизни подобное в CQRS только бывает, которое редко где действительно нужно

много вопросов:
1.  query и mutation по разному процессятся (query –  параллельно, mutation – строго сверху вниз)
2. какой синтаксис использовать для обновления вложенных данных?
3. как пометить поля, которые нельзя обновить в mutation?
4. я тут приводил пример со сложной мутацией “завершить оплату заказа”, когда мы меняем статус сущности “заказ”, создаем сущность “транзакция на счете” и заводим сущность “посылка на складе”, в твоей схеме клиент должен будет это все описать сам, так?

Обычно в языках методы мутаций видно семантически

Однако я приводил в пример руби

2. Так что получаем (если бы такое было возможно):

type User {
    name: String!
    email: Email
    rename!(name: String!): User
    changeEmail!(email: Email!): User
}

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

Если отвечать на первый вопрос, то это всё ненужная хрень

Это должно быть частью реализации, а не спеки

так, то есть у каждого поля есть поле-мутация, верно?

не обязательно

В программировании некоторые методы проектируются как read + write одновременно

Например:

type User {
    name(newValue: String = null): String!
}

а вот такое как реализовать?

type User {
  name: String!
  rename!(name: String!): User
  orders: [Order]!
  writeOrders!(orders: [Order]!): User
}

type User {
  name: String!
  rename!(name: String!): User
  orders: [Order]!
  writeOrders!(orders: [Order]!): User
}

А в чём проблема?

1. каждый раз пересылать список заказов и мучать сеть
2. на бэке сверять что там добавилось/изменилось/удалилось
3. если заказ новый – не надо ли какие-то еще сущности обновить
4. если клиент прислал что-то плохое (например статус заказа) – надо это заметить и ругнуться