Check out a free preview of the full Introduction to GraphQL course:
The "GraphQL Schemas Q&A" Lesson is part of the full, Introduction to GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

Questions are asked regarding where the GQL file gets used, if content is required to be returned, what the schema would look like in a real world application,

Get Unlimited Access Now

Transcript from the "GraphQL Schemas Q&A" Lesson

[00:00:00]
>> Scott Moss: Yes.
>> Student: Where does this GQL file get used?
>> Scott Moss: Good question. So other than the test where I'm testing it, actually I'll just walk you through how I'm using it in the test and I'll walk you through how it's being used in the server. Okay, so in the test the way it's being used is that I'm actually using that, when we started this, I walked you through this loadTypeSchema function in utils that takes a string and it loads up a schema.

[00:00:26] So it's loading it up, which just returns a string. So I take that string, and I take all the other schemas, and I merge them together just to create one big string. And then I use this also in the talk that I gave I said you can convert schema definition language to many different things.

[00:00:43] AST's, objects, so that's basically what I'm doing. I'm taking that schema string that I merged together and I'm creating an object out of it. And it gives me back the schema object. And the schema object allows me to like Loop over the types and see their names and their fields and their properties.

[00:00:58] So that's why I'm checking the test. I'm literally converting that string into an object that I can loop over and test. So that's what's happening in the test. In the server, how that's being used is you go to server js you can see that I'm using load schema again.

[00:01:13] And I'm going to load up all of the types called product, coupon, and user here. So I'm gonna load them up here, which creates just one big string of all those schemas, and then I pass them on to Apollo Server here. So that's where they're being used. Good question, any other questions?

[00:01:36]
>> Scott Moss: No, yes.
>> Student2: So in rest you have for updates and creates, you can return no contents.
>> Scott Moss: Yeah.
>> Student2: Here you're requiring returning.
>> Scott Moss: Yeah.
>> Student2: Can you change that to-
>> Scott Moss: Yep, you could do whatever you want.
>> Student2: Is there a reason why you're returning it?

[00:01:54] At least, is there a reason why you're requiring that you return it?
>> Scott Moss: No, there's no reason. Because it's really gonna be depending on who is consuming it, right. I would say because this API's meant to be a public API used by other developers, I'm just gonna give them back as much information as they want.

[00:02:10] Well let's say this is an internal API where your front end doesn't really need anything after you delete something. Then you don't need to return anything and you don't need to make it required. The reason I make it required is because if in my resolver I do a remove product and nothing comes back from the database this means this ID you gave me didn't find something.

[00:02:29] So if I make it required, I know you found something and you removed it, whereas if it wasn't required, that means you possible could not have found something, and you're not giving anything back. So I don't know if you didn't give me anything back because you don't have to or you didn't give me anything back because I didn't get to read it.

[00:02:44] So I don't know what the case is. So that's why I made it required. That why I know you deleted it but if your front end or your client doesn't need a response back from a update or remove then you don't have to put anything here. There is actually a lot of articles written about what do we do on GraphQL imitations, do we send stuff back or not and the answer is just like wow, what are you doing on the front end, it really depends on what you are doing there.

[00:03:03]
>> Student2: You could send back email, maybe.
>> Scott Moss: Yeah, it really depends on like so Apollo has a front end client that also keeps track of this data based on the operations that you perform, the queries you perform. And it requires these objects to come back so it can update them on the memory on the front, so that's another reason why I sent them back, because i'm not suppose to use Apollo on the front of them.

[00:03:25]
>> Student2: And then these IDs. So the client would have to know the IDs. How are they getting those IDs?
>> Scott Moss: And that's what he was saying. So he was like, in the real world, you have to add a ID type here like this. And I was like yeah, you do.

[00:03:37] Cuz otherwise how would you get an ID? So you have to add an ID type here. And these IDs will be the same IDs that come from your mongoose model. Yep.
>> Student3: And also you were talking about, everything comes as a data but you can send back status.

[00:03:52] I'm sure the status is also could be coming back right?
>> Scott Moss: The status is always gonna be 200 from GraphQL.
>> Student3: Okay there's no status that like other things that you can send beside data, bug?
>> Scott Moss: GraphQL, you're gonna find as soon as if there's an error in your resolver or if there's an error in your schema, it'll just send back, instead of that details and like that errors.

[00:04:13] Gonna be in an array of all the errors that happen whether they were validation errors or errors in your resolver. They'll send all those back too.
>> Student: I've seen that already.
>> Scott Moss: Yeah, you probably seen it already.
>> Student: [LAUGH]
>> Scott Moss: Yeah, so if you made a schema that wasn't correct, you'll see that.

[00:04:24] And then Apollo allows you to tie into that and format those errors to be whatever you want. So you can say, all right, don't send back stack traces to the front end. Let me format it or let me put a different message here or stuff like that so you can format those errors.

[00:04:36] Okay, what is a good way to decide on when to use the non null operator like string Non null is just a matter of if you can guarantee that you return that field. I say a good time to do that is one, if your database is saying it's gonna be there.

[00:04:51] So for instance, our database says on the product schema that a name is definitely required and it has to be there. So because the database says it has to be there, I could be sure that it should always be there. So my GraphQL schema's also gonna say that it should be there.

[00:05:04] So that's why I'm gonna do that. The other time is like yeah, pretty much if you can guarantee that it's gonna be there and it should be there. Then yes, you should put a bang. If you can't guarantee that it's gonna be there for instance like description. Description is not required, you may be or maybe not add a description for this product.

[00:05:21] Well in that case I won't put a bang there because It won't be there. Unless inside the graph cure resolver I decide to add a default description for every single one that doesn't have one. Then I would make it required because I default to it anyway. So I can virtualize that myself.

[00:05:35] So you can see a lot of similarities between validating on the database level versus validating on the GraphQL level. But you could piggyback off of what your database is doing by default with GraphQL, and if not you can add validations later inside your resolvers.