Single mutation arguments? about opencrud HOT 8 OPEN

@SachaG Thank for the clarification!

It would make more sense to keep the "top-level input argument" pattern for the input because it seems this pattern is recommended for payload as well.

Just like when you design your input, nesting is a virtue for your GraphQL payload. Always create a custom object type for each of your mutations and then add any output you want as a field of that custom object type. This will allow you to add multiple outputs over time and metadata fields like clientMutationId or userErrors.

from opencrud.

I think the last one is easier to use (from a front-end point of view) because you've only one argument to pass, and you don't need to pick the where condition from your object. In most cases, we're manipulating an entire user's object (in our states or reducers) and it's easier to send it directly into this input argument.

Moreover, when you're compatible with multiple DB with different identifiers (id, _id, ...), the last one is better again to handle it smoothly in the back-end. It's painless for front-end developers to use 👍

from opencrud.

Just to clarify, I think a better example would be:

• multiple arguments:

updateUser(where: { id: "1" }, data: { name: "Karl" })

• single argument:

updateUser(input: {where: { id: "1" }, data: { name: "Karl" }})

So the mutation still requires the same arguments, they're just nested inside a top-level input argument.

The idea being that if you then create a new version of your API with new arguments your mutation can then become (for example):

updateUser(input: {where: { id: "1" }, data: { name: "Karl" }}, input2: {query: { _id: "1" }, payload: { name: "Karl" }})

from opencrud.

For the payload I agree, but I was talking with @schickling and @sorenbs and we weren't sure if that pattern also made sense for the input.

from opencrud.

I tried to iterate with the example you gave me.

updateUser(input: { where: { id: "1" }, data: { name: "Karl" }}, input2: {query: { _id: "1" }, payload: { name: "Karl" }})

Without the top-level input argument, we could definitely do something like that and it does the same thing.

updateUser(where: { id: "1" }, data: { name: "Karl" }); // Old apps will use this query

updateUser(query: { _id: "1" },  data: { name: "Karl"}, payload: { name: "Karl" }); // New apps will use this query

I added a new argument payload, query to the top-level argument definition and _id for the query input definition. Since I've only added new things it doesn't break anything. Except that I can't rename/remove the top-level where argument and id from my current definition to not break the old apps.

I've certainly missed something in my thinking but it seems the only pain caused by the OpenCRUD specifications. You can't delete the top-level arguments but you can still rename them by adding new ones and use these new arguments instead of the old ones. I don't have any example in mind where I would need to rename the where and data arguments for a CRUD usage. It's pretty generic!

from opencrud.

I think I'm leaning towards not following that pattern. My mutations have at most 2 arguments anyway so I don't think it's worth adding that extra level of indirection all the time.

from opencrud.

strapi v3 is currently following Facebok/Apollo's recommendations with only one input & payload.

cc @Aurelsicoko

from opencrud.

There is an advantage of the "one input", for example MongoDB specifically distinguishes between update(One/Many) vs. replace(One/Many), and then we also have findOneAndUpdate() etc.

With OpenCRUD current draft:

mutation {
  updateManyUsers(where: {name_not: "Karl"}, data:{name: "Karl"}) {
    count
  }
}

Currently it doesn't seem to be possible to update individual fields (for example set viewCount=viewCount+1, or in MongoDB-speak {$inc: 'viewCount'}. Even if we add another mutation, the flexibility of single input is good here.

Also with update, we can't specify whether we want previous value or updated value, as MongoDB's findOneAndUpdate() allows. This requires another (optional) argument, and this could be put inside the single input instead of adding a third/etc. argument.

With updateManyUsers maybe client wants to know results not just count, and when dealing with multiple items then client will want to specify sorting, then this requires another argument in the mutation.

from opencrud.