GraphQL мутации на вложенные ресурсы

Question

Мутации запросов для манипулирования данными. Если это так, то мое дерево root query и root mutation должно выглядеть так же верно? Оба они должны допускать вложенные поля (вложенные мутации). Я играл с этим (используя express-graphql), и он работает.

Пример:

// PUT /projects/:project_id/products/:id 
mutation { 
    findProject(id: 1) { // make sure that project exists and we can access it before mutating data 
    updateProduct(id: 1, name: "Foo") { // the resolve function receives a valid `project` as the first argument 
     id 
    } 
    } 
} 

Является ли это действительный пример? Должны ли мутации быть подобными? Если нет, как мне обрабатывать вложенные ресурсы? Я не могу найти реальный пример, который бы мутировал вложенные ресурсы. Все примеры определяют мутации только на первом уровне (поля на корневой мутации).

Answer 1

Продукт имеет уникальный идентификатор, так что это все, что вам нужно, чтобы идентифицировать его.

mutation { 
    updateProduct(id: 1, name: "Foo") { 
    id 
    } 
} 

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

resolve({ id }, { user }) { 
    authorize(user, 'project', Product.find(id).project) // or whatever 

    ... // update 
} 

---

Старый ответ:

Это, безусловно, является действительным примером.

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

Другой альтернативой было бы включить идентификатор проекта в качестве аргумента в updateProduct:

mutation { 
    updateProduct(projectId: 1, id: 1, name: "Foo") { 
    id 
    } 
} 

Ваше решение кажется лучше для меня, хотя.

---

В качестве примечания, мутации, по сути, точно такие же, как и запросы. Единственное отличие состоит в том, что функция resolve обычно включает в себя некоторые постоянные изменения, такие как изменение некоторых данных. Даже тогда, хотя мутация ведет себя точно так же, как запрос, - проверяет аргументы, функцию разрешения вызова, возвращает данные объявленного типа.

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