Transcript from the "Info Object AST" Lesson
>> Scott Moss: And then here's the fun one, it's info. So let's just look at this one, because it's easier just to look at, and then to see yourself that it is to like talk about, so let's just do that.
>> Scott Moss: Let's make another one here. Yeah, now where did I do that?
>> Scott Moss: I did it in on the ID, okay, ID's not so bad. It should be pretty simple, then, let's see. All right, and wow, ID's actually really big, okay. So this right here is the raw GraphQL AST, right, so GraphQL is basically a language, it is a language.
[00:00:45] So it has an AST, and that's how they do validations. You can actually hook into the AST and do some really advanced things, like write your own custom validations or your own scholar types. You can do all types of crazy stuff. But this is the raw AST. And the reason this can be useful, the only time I found this useful is when I wanna do something called like field projection.
[00:01:09] Basically, when I want to only query the database for the specific fields that were asked for in the query, I would use this to optimize my database queries, right? But that would only work if you have like fields that were exactly same as your GraphQL types. Like for here, I have a name, a description, ID, I have all these fields.
[00:01:30] So if my database model looked very similar this, and someone wrote a query with those field I could take the fields from the query that they wrote, and pass them directly to my database, and say, only grab these fields, which will optimize my database queries. That's a very useful example that I've seen.
[00:01:47] But again, your database schema needs to match very closely to your GraphQL schema. And I would argue that if they do match up that close, you're probably not using GraphQL to its full potential. Because you could be doing a lot of virtual things with those schemas that you aren't doing, because you made them look exactly the same.
[00:02:03] You're basically using GraphQL as like a day to day schema, and not so much as an API schema at that point and this is like, what's the point of that? So there's some trade offs. And I'm sure there's some more advanced use cases, but in the while, that is the only time I've ever seen anyone use info is that.
[00:02:18] I've never seen it used anywhere else. I can think of some other examples you might use it for, for caching, invalidating caching, different things like that, changing different things on the query, but most of the time, it's just for that, and for tooling. If you use Apollo Engine, they use the info to figure out tracing and things like that.
[00:02:40] But it's mostly for tooling and for projection on the database queries. So you will almost never use this. Basically, that's what I'm trying to say.
>> Speaker 2: [INAUDIBLE] used to determine complexity to, obviously, disallow overly complex queries?
>> Scott Moss: Yeah, now that's really advanced. And yeah, we were gonna talk about some of that.
[00:02:57] Sounds like you've been doing some research. But what he was saying is you can use it to disallow over advanced queries. You'll find out soon that, these queries are gonna get recursive, and people can just DDOS your entire system with one query. So, how do you prevent that?
[00:03:14] You would look at this. Like, I'm gonna look at this AST. I'm gonna see how deep it goes. I'm only gonna allow you to go four levels deep, then I'm going to stop you. Some people do that, or what they'll do is they'll give points to certain types, or this person type is worth four points, and this task type is worth two points.
[00:03:32] And a query can only have 20 points before it craps out, things like that. There's so many different things you can do to prevent things that like. And this is where you would do it, is in AST. So it's specifically for tooling and advanced cases in database protection stuff.
[00:03:47] But yeah, you will almost never use this. And if you are, then like you're on the edge. You've jumped off the edge with no parachute.