Fork me on GitHub
#graphql
<
2017-11-01
>
youvere20:11:06

Hi guys, first of all good job for the great work and thx for all the contributions you did in the opensource community 🎉. I was wondering, is there a way to enforce the client to respect a schema and deny the request server side if the client doesn’t respect the schema. I would like to define only in one place what a client should be able to do. This request will be resolve server side even if the id parameter is null and the input object doesn’t accept null parameter.

mutation ($users: [user]) {
  createUsers(users: $users) {
		id
                name
  }
}
{"users": 
  [{"name": "Bob", "id": 42},
   {"name": "Rob"}] ;missing property id
}
{:input-objects
 {:userInput
  {:fields {:name {:type (non-null String)}
            :id   {:type (non-null Int)}}}}
 :objects
 {:user
  {:fields {:name {:type (non-null String)}
            :id   {:type (non-null Int)}}}}
 :mutations
 {:createUsers {:type    (list :user)
                :args    {:users {:type (list :userInput)}}
                :resolve :create-users}}}
This would result into an error like this
{
  "data": {
    "generateLicenses": [
      {
        "id": "42",
        "name": "bob",
      },
      {
        "id": nil,
        "name": "rob"
      }
    ]
  },
  "errors": [
    {
      "message": "Non-nullable field was null.",
      "locations": [
        {
          "line": 2,
          "column": 40
        }
      ],
      "query-path": [
        "createUsers",
        "id"
      ]
    }
  ]
}
Thx 🙂

hlship21:11:38

This looks like it worked to me ... you submitted an invalid user (missing the not-null id property) and got an error back ... ah, I see, you also got some execution going on.

hlship21:11:51

That's part of Lacinia and GraphQL I think: accept and report errors, continue as well as possible.

hlship21:11:17

We don't expose to the field resolvers any errors that may have occurred.

youvere19:11:39

alright I’m going to do the validation twice, I was wondering if it was a bug or an expected behavior tyvm

hlship22:11:57

So I don't have an answer for you. Perhaps invalid input objects should be considered a validation error (in which case, no execution takes place and no "data" key in the result map).