Interfaces Q&A

[00:00:00]
>> Scott Moss: You can see this is a really good use case if for instance, you're returning a list of very similar items but with slightly different fields user interface, because they're very common but they differ slightly. And then you will need a special syntax here to say cool, give me the common fields.

[00:00:16]
But on this type, give me these fields, on this type, give me these fields and etc, etc.
>> Speaker 2: Can you query their type inside of that as well?
>> Scott Moss: Can you query their type?
>> Speaker 2: And can you get boot or sneaker?
>> Scott Moss: So there's a special thing called, I don't know if it's gonna work here, you do type name, type name let's see if this works here.

[00:00:35]
Yeah, so video I'm just going to type name you'll always get the type of any type. And that's anything with graph deals, so yeah, you can do that. Good question, any other questions?
>> Speaker 3: Did that type name go outside of that interface?
>> Scott Moss: Yeah, you could put that type name pretty much anywhere.

[00:00:56]
There you go.
>> Scott Moss: Wherever you want, you can put-
>> Speaker 4: It looks like it's only allowing it to appear in one location though. So for example, interesting, cuz it hides it on-
>> Scott Moss: Yeah, cuz these are on the same level, yeah.
>> Speaker 2: So it's showing once.
>> Scott Moss: Right, this field and this field are on the same level, so the second one overwrites it, right?

[00:01:23]
This looks like it's overwriten cuz I got this object here, well, all of these are sibling fields. Everything inside this shoe are siblings So this one just gets ignored. I'm like asking for the same field twice so it's like okay, cool. Any other questions on interfaces?
>> Speaker 3: Is there a reason that they have you type out those fields and on all the interfaces twice or is that just like a limitation of this apollos implementation?

[00:01:51]
>> Scott Moss: No, it's, that's the spec, it's very annoying. Trust me, I wouldn't-
>> Speaker 3: Kind of the same reason that they don't want to help us with strict when you're querying things.
>> Scott Moss: Yeah, I think they're always going to go down a path of being extremely explicit of looking at stuff because you got to think about it.

[00:02:05]
All right, cool, we're one follower right now but imagine you have multiple files and the interface was all over here. How would you know what fields are on this type if you're looking at like you got to go navigate. And then you get it, gets even crazier when you start combining schemas from different servers together.

[00:02:21]
You literally won't know what the fields are unless you went to the other server or looked at something. So they always try to have it at the point where I can just look at a server, or I can look at a schema and know exactly what I'm gonna get back without having to go look at other sources.

[00:02:36]
Just look at this one place, I know exactly what I'm gonna get. So I think they try to do that as much as possible and It has to be that path but there's issues about this. There's literally open issues on GraphQL, like, we want to not do this and they're like, cool.

[00:02:49]
>> Speaker 3: Cuz I think the other way, too, is if you have this interface and you wanna just update that now you have to go and find every place you've used that.
>> Scott Moss: 100%, yeah, this is not for the purpose of, like I said, brevity, it is not. It's only for the purpose of not creating more queries because if I didn't have that, I would have a sneakers query, then I would have a boot query.

[00:03:07]
Right now, all I need is a shoes query and I could get both, that's what it's for. It's not for what we're used to with the type systems, like, cool, we got interfaces because we don't wanna write the same code again. No, it's not for that. It's for not writing the same queries again.

[00:03:20]
Yep, Mark?
>> Mark: If I had two data sources and both had the same common fields, how will GraphQL choose the resolver?
>> Scott Moss: 100% the same thing we just did nothing changes because GraphQL has no clue what your data sources are. In fact this array that I just hard coated could have in from 10 different data sources, it doesn't matter so you would still have to do the same thing.

[00:03:45]
It's still your responsibility to format the response of that resolver to match the types that you specified in your schema. So doesn't matter what data source it came from you still have to format it. You can format it all in a top level resolver like I did here or you can write a field level resolver for every single thing that comes back out of the database and resolve them individually.

[00:04:05]
But at the end of the day, you still have to make a resolve type that's gonna get an instance of a shoe. And you need to check some type of logic that you created to return to the name of the type. That doesn't change no matter where the data source came from.

[00:04:20]
In fact that a the one thing that does not determine how GraphQL works is the data source. It's gonna do whatever it wants, it's gonna determine how well it works, it's gonna determine how secure it is and how fast it is. But it's never gonna determine how it works.

[00:04:35]
It's gonna work exactly the same no matter what data source you use. Any other questions?
>> Speaker 6: So aside from enforcing the next foot where item you add has the correct all the fields that are required there to make a shoe or makeup. I don't see any benefit to having interface because the shape of the object you return as long as it looks like the thing you've defined which you have to define anyways, and you're not, I mean, you could have any number of queries no matter what.

[00:05:04]
Even with that interface, you have one query for all of the footwear that returns is a matter of different kinds of objects, is a matter of different kinds of sources. Is it simply to enforce the fact that every new footwear type you add has the required fields?
>> Scott Moss: Well, to demystify some of that without an interface, there's no way you could return a list of things that are dissimilar.

[00:05:28]
They all have to be exactly the same, there's no way to do it. Let's go back and look at what we've done so far. There's no way for me to come down here and say I want to return a sneaker and the boot, like you can, it's only one type.

[00:05:45]
But there are scenarios where in your client side application where you wanna list of all these stuff that's basically the same but slightly different. So you would wanna do this, that's the scenario yeah, cuz there's no other way, it's too explicit