Unions

[00:00:00]
>> Scott Moss: So unions are pretty much exactly like interfaces except for one could eat. They don't have any similar fields. A union is just like this type or this type or this type or this type. They may have similar fields, they may not have similar fields, doesn't matter. It's just it can be either one of these types.

[00:00:16]
And that's basically what a union is. The difference between a union, or why you would use a union over an interface is, I mean, the only use case I could think of like something like a union, as far as from a UI perspective is like a search. If you had a global search and you could search for many different types of entities throughout an application that have nothing to do with each other, a union is perfect for that.

[00:00:35]
Because they have no relation, they don't share any common fields. But you want to do one query and get all of them back. You would do a union. That's basically it. And the syntax there is a lot simpler than an interface, because a union will look something like this.

[00:00:50]
You would say like union. I'm ran out of shoe stuff here. So [LAUGH] you could say like union thing. And you say, equals, and then you just start putting types here. You say, like, I know what we'll do. We'll say, instead of shoe, we'll put, what's another word for a shoe?

[00:01:12]
Footwear, [LAUGH] man, it's so good. Footwear equals a sneaker or a, what do I have, boot. Not body, look at that. Boot, and that's a union. And it's exact. You have to treat it exactly the same way as you treat an interface. You have to create a resolver for it that resolves the type.

[00:01:37]
You have to use the dot dot dot syntax. Where is that? You have to use this syntax to say individually for this one, I want these fields. The only difference is if you were using unions, you wouldn't have any common fields, there would be no common fields here.

[00:01:53]
Everything will just be like, dot dot dot, dot dot dot, dot dot dot. It's just, there's no common fields. Maybe you do with some of them, but you don't know. So, and you didn't specify. So GraphQL doesn't know. So even if there were common fields, you couldn't do that.

[00:02:04]
You still had to do dot dot dot. And it's basically how it works. Yes?
>> Speaker 2: Under the hood, what is union Footwear doing there?
>> Scott Moss: It's creating a new abstract type just like an interface is that you can use in place of scholars on queries.
>> Speaker 2: So it effectively contains a result set of, or could contain a result set of all sneakers and all boots?

[00:02:35]
>> Scott Moss: Yeah. Or, it can be or. It doesn't have to be and, but it can be or. It can be and, but it doesn't have to be and. It could also be or. You could just have one thing in there and one of them is a sneaker and it's fine.

[00:02:46]
You could have ten things in them, five are sneakers, five are boots. That's fine.
>> Speaker 2: Right, but it's a starting point for filtering down.
>> Scott Moss: Yes, exactly. Again, its purpose is just so you can make one query. That's what it's for. It's like, I just need one query where I can get this or this or this.

[00:03:03]
It's basically what I told you you couldn't do, this is how you do it. I was like, you can't put a comma in here, say I want an array of all this stuff. You don't have to. Now you can just say it's a footwear now. You can just say footwear.

[00:03:14]
And that's how you do a comma separated, like it's an array of this and this and this and this and this. That's what union's for. And I don't know if any of them have anything in common. Because if they did, I would make it an interface. If they don't have anything in common, it's just a union.

[00:03:30]
Up to you when you want to pick them. As far as GraphQL's concerned, when it comes to resolvers and queries, they're exactly the same thing. Yes?
>> Speaker 2: Is there a difference in performance, or one versus the other?
>> Scott Moss: No, there's no difference in performance. No, because as far as the code that you write, there is nothing different about what you do.

[00:03:53]
As far as how GraphQL resolves it, no, the GraphQL doesn't even resolve things at asynchronous anyway, everything's pretty much. Yeah, there's there's no difference. It shouldn't be anything. The only difference like I said, is just going to be your queries. You're not going to have any common fields here.

[00:04:07]
It's always going to be this for unions. Always. Any questions on unions?
>> Speaker 3: Do the client libraries have a way to kind of automatically resolve how to write, say you had a union that took every model, every type you have, and concatenated it together as a global search.

[00:04:26]
Does the client side have any way to kinda write that, to splat out all those ons for the query itself when it asks for it? Or do you gotta?
>> Scott Moss: Not by default. It's not by default, but there's a lot of tools. So it depends on, if you want to pay for something or if you want to not pay for something.

[00:04:43]
So there are services that you can upload your schema to remotely, and then you'll have a plugin in VS Code that reads that schema remotely, and it gives you tools inside your editor that whenever you write a GraphQL file, it gives you autocomplete just like this does, inside of VS Code, cuz it's reading your schema from remotely.

[00:05:01]
That's something you've gotta pay for. Or you can hack it together yourself. There's other ones where you can just copy and paste the schema from your server and paste it in your client site repo, if they're not in the same repo and have your tool read from that.

[00:05:12]
It's just, if it gets updated, you've gotta do the copying and pasting yourself. So that's another thing. I think a lot of people do is a cheap alternative, they'll write their schema, they'll push it up to the CDN somewhere. And whenever their schema gets checked into GitHub, they update the CDN with that schema.

[00:05:27]
And then the frontend app just pulls down from that CDN and is always up to date with the right thing. So that's like a cheap way to keep it automatically updated if you really want those tools. And a lot of people really depend on those tools, because they go a step beyond, take that schema on the frontend and generate like TypeScript for the response of the data, which is really cool.

[00:05:47]
Cuz it's really hard to get TypeScript support for something dynamic from data that comes a server. You don't really get that, well, because GraphQL is strictly typed, you can get that now. So now, you no longer have to say data is type any from the server. Data is exactly this type, cuz I know what it is, and it's generated for me.

[00:06:07]
So a lot of people invest a lot of time into that. Cool, any other questions?
>> Speaker 4: You said you need to write a resolver for the union. Like for footwear, where do you write that resolver? Is it under shoes, or?
>> Scott Moss: It's a good question. You would write it.

[00:06:26]
Just like you wrote one for shoe, you write one for footwear.
>> Speaker 4: So it's its own exclusive one.
>> Scott Moss: Yep, it's its own thing. And it's basically the same thing. You would just copy that and put that there, done.