Multiple Queries & Mutations

[00:00:00]
>> Scott Moss: I do wanna get into a little other cool stuff. I think that'll be super helpful in your journey with front-end graphql and stuff like that. So one thing to note here is a really cool feature called aliasing using queries and mutations. So if you have fields, like in this case, we have a field called name.

[00:00:20]
What else do we have here on a character? Name, status, species, type, gender, origin, image, episode, all this stuff. So if I wanted to, for instance, we get a name here, but let's say in the component of my UI, I'm not looking for a character.name, I'm looking for a character died.

[00:00:41]
Full Name, something like that, it's not name, and I don't wanna go change it in my component. So I just want to change it from grayscale, so I can stick his trademark component. But I also don't have access to the server to go change the whole API, or maybe something else is using name.

[00:00:55]
And if I change it on the API level, it's gonna break everything else. So I don't wanna change the name. But I also don't wanna change it and my react app. So what do I do? This is where alias is coming. So with an alias, I can just put whatever I want.

[00:01:10]
So left of it like that. And now, I can Alias Name with whatever I want it to be, in this case, full name. So if I were to do that, it changes the format. This is really cool. One of the things I like to do with aliases is, if you notice, when whatever query or mutation, you run the name of it.

[00:01:29]
That's what you get back at the response. So you'll get data dot whatever the query name is. Sometimes, I don't like that and this cases were done is already results here. But sometimes, I'll do something like, results. And I'll actually A list a querie, and I'll make sure all of my queries have data dot results or something like that verses data dot, whatever the name of that querie is, and having to figure it out every time and going back.

[00:01:55]
I just always A list it to a standard name that I always use for every single querie, and I can look for it that way. So that's one thing to know, but yeah, you can alias any field that you want. Another good example of doing aliases, is if you have conflicting fields from union types or from interfaces, you can do aliases to change whatever those field values are, and stuff like that.

[00:02:24]
That way you don't have that that collision there. So really another good example of that. The other thing is you can run multiple queries in one API call. So if I wanted to run another query simultaneously within the same operation, even the exact same query, like I could just do this.

[00:02:41]
I can just copy this and run this again. If I try to execute this with both queries happening simultaneously, graph QL can support that. But when I execute them right now, it actually won't run too, and that's because they're both the same name. So by default, this is gonna get de-duplicated.

[00:03:04]
It's gonna realize like, you're actually already running a query with the exact same name, so I was only gonna run them once, I'm gonna de-duplicate it for you, or to get this to run, I would have to alias this to something else. And then, when I execute this, you can see I get something else down here.

[00:03:24]
So that's another good example of using aliases on field levels, is to help you resolve the point where you have like multiple queries running at one time. And then, on the server side, this is all gonna happen pretty much in parallel. So this is you adding multiple queries to one operation, but at the same time, depending on what framework you're using, you might be running multiple operations at one time that all get batched, as well.

[00:03:50]
So if you think about let's say you load up your app. Your app started up, and it had an operation that ran for the nav bar to get the user. It had a operation for whatever page you're looking on to get the main data. Another operation that ran that did something else.

[00:04:05]
Each one was operations had 10 queries inside of them for some reason. That's 30 queries, your server is gonna be executing at pretty much one time. So something to think about there. But as a front end person working on this, you don't care. I guess, it doesn't really matter, but just something to think about when you're executing your careers and putting them together.

[00:04:27]
There's a lot of other cool stuff that we'll get to with queries, and mutations, and things like that. But, for now, yeah, this is it. And then, I guess, on the flip side of this, I've been talking about queries for mutations if you want to do a mutation operation.

[00:04:42]
It's very similar to a query operation. You just use the mutation keyword. And then, you also just do, I don't think this API has any mutations. Which is why I can actually execute. Yeah, there's no mutations on this API, but you can just do mutation followed by whatever operation you want.

[00:04:58]
Let's say I was creating a character
>> Scott Moss: And I wanted some variables there, and if there was a mutation, I would use that one here, createCharacter.
>> Scott Moss: That is the same thing, it follows the same rules as the query. So the only difference here is you use the mutation keyword to the left versus the query keyword, that's it, nothing else changed.

[00:05:25]
It's the exact same thing, the same variable rules, same, all of that stuff. So all good to go, yes?
>> Speaker 2: So what's the point of naming mutations? Will those be cached, as well?
>> Scott Moss: That's a good question, will mutations be cached, as well? No, mutations themselves aren't cashed, because, yeah, they're not really cached, but the operations are still gonna be indexed.

[00:05:51]
So you can reference them through tools, and you'll see another tool that we're gonna download for react that, it's very important to name these. But as far as like the data being cached, no, they're not going to be cached for you like a query would, at least not with the library that we're using, some libraries might do it, but, no.

[00:06:12]
The reason, I think, it's important to, to also just put these names on them, is because you might not, you don't really understand unless you built it what the tools you're using are gonna be doing with them. So in that case, I tend to just always add operation names when I'm doing client site implementations, because, I have no idea what this library that I downloaded is expecting, what it's doing with these names, if it's planning on indexing, if it's trying to cache them, or if it's doing something smart that I'm not aware of, always just provide the name for it.

[00:06:45]
But, no, you’re not gonna have cache mutations. Only query results are going to be cached. And we’ll get to the point, how do you update a cache after you mutate something. Cuz you will have to do that. So we’ll talk about that.
>> Speaker 3: What’s that across the wire?

[00:06:59]
There's a string posted?
>> Scott Moss: Good question. So there's a lot of ways that this could happen, as a get request, then this is going to be a query string on the end with, I think the parameters literally, or the query is actually called query equals, and is literally your query string of fire, up to the maximum character, whatever can be.

[00:07:20]
Same thing with mutations. Mutations can also be on the get request. And that happens to the most time is gonna be a POST request. Post requires, I believe, it's going to be a body that has query in it. And it's gonna be your query as a string, and there's variables, there's gonna be a field called variables, and that's gonna be your variables object.

[00:07:37]
And that's basically what gets it up. But yeah, most of the times, it's gonna be a post request, unless you're doing something persistent query, or something like that where you can still get request what the URL, you're good to go.
>> Speaker 4: Is there any support for like something in this one if you have list of characters and they have a list of episodes, rather than returning all the episodes in the field on there, just returning like the number of episodes?

[00:08:03]
>> Scott Moss: Yeah, that's a good question. So there's a couple of ways that you can support that. The easy way, or the obvious way is whoever made the API needs a supportive field that says episode count, that's one. The other thing you could do, and all of these are gonna require someone on the back in doing something, the other thing you can do is have a directive that we haven't talked too much about directive or directives at all, but, basically, you can have a directive that might say, I don't know, it might have something in here called count or something like that.

[00:08:40]
It could do anything, a directive could literally do anything that allows you to get that, I know there are some really cool ones, Lodash, GraphQL. Let me see if this is still a thing. So this directive library is something that you can add to GraphQL that allows you to basically use Lodash inside of a query, which is really cool.

[00:09:02]
So something like this might be able to offer you that flexibility without having to ask the person working on the server to change something, but, yeah, most times, it's gonna require a backend change.