Advanced GraphQL

Advanced GraphQL Q&A: Mutation vs. Query & Type vs. Input


This course has been updated! We now recommend you take the Advanced GraphQL, v2 course.

Check out a free preview of the full Advanced GraphQL course:
The "Q&A: Mutation vs. Query & Type vs. Input" Lesson is part of the full, Advanced GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

Scott talks about mutating the database on the query and recommends against this approach. Then Scott answers a question was asked about using types as inputs and being able to define the types as inputs all the way down.

Get Unlimited Access Now

Transcript from the "Q&A: Mutation vs. Query & Type vs. Input" Lesson

>> Scott Moss: Is there anything stopping you from performing create, update, delete operations from within a query resolver? There's nothing stopping you from doing that, and in fact, sometimes when you do queries they have side effects that might force you to do create, update, and deletes, but as far as the expectation of what a query does, it's not expected that it's gonna do a mutation.

[00:00:26] So I would think of mutations inside of a query as more of side effects and not a direct thing.
>> Scott Moss: Let's see, can we use user-defined types in the input instead of using the string? Yep, that's what input types are for, however, you cannot use a type inside of a input.

[00:00:49] So, if I were to have a type called Args, and it was a type of Args, let's just say string, and then I had a query,
>> Scott Moss: That was like getArgs or getThings, and I wanted to use the Args as the input, I couldn't do this, because Args is a type and not an input.

[00:01:17] The only thing I would have to change is that to input.
>> Scott Moss: It gets a little more complicated when you have nested types. So if I had another type here called Person with a name: String, and instead of putting name here if I wanted to say you've got to pass a person, I also could not do that, because although Args is an input, person is not an input, it's a type.

[00:01:52] So that would have to be an input as well. So basically to use an input, to use a type as in input in [INAUDIBLE] everything has to resolve to an input no matter how deep. Every single property either has to be an input or a scholar type, and a scholar type are just String, Int, Float, Boolean, ID, yeah.

[00:02:21] So it either has to be one of these, or a input type. You can't put a type, in an input, even if it's the exact same shape as another object. It has to have the word input in front of it. So, that kind of gets repetitive. Hopefully they'll work on something that fixes that.

[00:02:41] But yeah, that took me a while to figure out. Kinda hurt.