tRPC in the Client

[00:00:00]
>> Steve Kinney: Now for our next trick, let's talk about using it in the client, right? Cuz having a bunch of new endpoints doesn't really do much for me. Cool, so let's go ahead and we're gonna over into the API part of our client, I believe. So now we've got these fetch tasks, so on and so forth.

[00:00:34]
All we're gonna do is pull in import{create}.
>> Steve Kinney: The client, what you angry about?
>> Steve Kinney: TRPC is a proxy client. Of course, why not?
>> Steve Kinney: Cool, and so this will do stuff too, which is, if it can batch requests together, there will be a whole bunch of other fun, little, not dissimilar to what both gRPC and GraphQL do as well.

[00:01:12]
Where it will try to do other helpful things for you, in the name of performance. And now we're gonna say,
>> Steve Kinney: And all it really needs is access to that router, which I think that I did
>> Steve Kinney: Yep, export const router. And the nice part is it actually doesn't need the router itself, it only needs the type, right?

[00:01:56]
It's very much like when we when we created that client from the Open API spec. As long as you give it the type, it will do all the right stuff out of the box, which is kinda nuts.
>> Steve Kinney: So really all we want is the type in this case.

[00:02:31]
>> Steve Kinney: And what we'll do is we'll give it a link. In this case, yep, that's the right URL. And now I have this client, and the cool things the client can do, in this case, is we can do,
>> Steve Kinney: As you can see, out of the box, just by importing the type, that's it.

[00:02:54]
The only thing on the client that we're really pulling in is this little, create me a client. And then get telling it about the contract, that's it. And then we can see it's got getTasks, right? If we look at getTasks, it looks kind of crazy, but you can see that completed Boolean or undefined, it will have the right output.

[00:03:16]
Everything is built-in and ready to go. So what we could do theoretically, is, instead of sending fetch requests now, we could just go ahead and literally just pull in things. So all this right here, let's go ahead and let's do,
>> Steve Kinney: New, single task. And you could argue, do I need to keep these abstractions?

[00:03:52]
We don't ever actually use a single task, I'm gonna leave that one for a second. No, but then you have to watch me go around a React code base and swap them out all over the place. So we'll just change the implementations here. So here we'll have return client, and this was actually gonna be that,
>> Steve Kinney: CreateTask type.

[00:04:21]
And again, it knew that partial task was not what I needed. That was that weird fake type that I made earlier. It automatically knows that's not the type that the server expects. Give me the type that the server expects, please, which is super cool.
>> Steve Kinney: Return client.updateTask. And again, these are all defined on the server that says basically what it is looking for and what it wants, right?

[00:04:58]
>> Steve Kinney: And automatically enforces the types. And then you will see that it is fulfilling all these explicit return types with no red squigglies. So out of the box, it knows the types of server expects, enforce the types the server expects. It knows the types of server gives back, it enforces the types that the server gives back, right?

[00:05:20]
So there's no necessary need to go into Zod schema the world, right? You basically, will get the type safety as generated by the server, and all those long, long ones, right, simply become calls to the client, right? Either mutates or gets and everything is type safe across the entire board.

[00:05:38]
Now, obviously, the moment of truth here is going to the app and making sure it works. Which am I stalling a little bit cuz I'm scared? Sure, well, let's do it. I feel good. Let's see, let's go local host, API, trpc. Hey, all right, there was a little moment of drama and suspense, but it wasn't bad.

[00:06:12]
We can add it, we can move it to completed, so on and so forth, right? And what's super cool is, I basically guessed there was some boiler plate. Let's all acknowledge that. But I think the cool part is, once I got that boiler plate out of the way, cuz a lot of times in a workshop, the boiler plate takes up 50% of time.

[00:06:31]
In life, the boiler plate takes up like 0.001% of the time. But because the types are shared, you do need to figure out a way to, again, you can put that in the shared repo. There is a little bit of type script specific jumping you need to do here.

[00:06:49]
But if that's not an option, then the open API scheme is a great option. No matter what, it becomes a what is the reality of your situation, not what is the best, right? Unfortunately, those days ended a long time ago. But now, we get all the type safety, and we're getting a lot more of it for free and automatic.

[00:07:10]
If you can get away with this, great, do it. If you can't, the stuff we did the very beginning still valid and useful, depending on what area you can go to make your life better. The only wrong choice is just hoping that everything works all the time and praying, right?

[00:07:25]
For no back end API to ever change or something along those lines. In this case we know that if even if they do change, I will get red squigglys immediately. I know even if the API does change, to know how it happened versus the times that they have changed behind my back has been deeply problematic.

[00:07:44]
Cuz a lot of times it is after an hour figuring out why, especially in the days of undefined, is not a function, right? Or something like that, or undefined.map, map is not available in undefined. And then you trace that down and that takes the better part of a day while the site is down, I would rather have the types tell me exactly what the issue is, right?

[00:08:07]
So even if you're not totally safe at all times, the way to solve everything is a lot easier. And like I said, one more time, yeah.
>> Speaker 2: I'm just gonna ask a question about trpc versus rest, and if there's any speed differences with request time.
>> Steve Kinney: I mean, trpc will do a bunch of stuff, we turn this on, there's batch updates.

[00:08:30]
If we can kind of coalesce them, it has the ability to update stuff over web sockets and then fall back, and a whole bunch of stuff like that. You can even do stuff like, kind of hand waving, we've mentioned. There's stuff in thein the course notes about how to do subscriptions.

[00:08:48]
So you can do stuff where it's like, if the data changes on the server, to push the updates to the client without having to refresh it, there's a bunch of stuff. What do you pay for that? You pay for complexity, right? Now you've got stuff coming over web sockets, all that's great, a little harder to debug sometimes, right?

[00:09:11]
Also a lot of the stuff with the sockets and stuff like that does kind of involve a persistent existing server. So you add some complexity, if you're serverless, right? You get it? It is, in a lot of ways, going to be faster and more performant. On the other hand, you pay for that with complexity, right?

[00:09:32]
And it all depends, but the fact that you can call functions with different parameters and all that kind of stuff, and almost in a lot of ways, expose stuff at a lower level. Means, if you're still prototyping and figuring stuff out, incredibly powerful. So extra complexity, more freedom, probably for most cases, a little bit better performance.

[00:09:53]
But nothing like an HTTP call when you're trying to debug. So it's a set of trade-offs in any direction. And it's like, what poison do you wanna pick?