Supper Club × tRPC With Alex KATT Johansson

Welcome to the Syntax supper club where today we're Talking with Alex Johansen about TRPC, what it is, what you need to know about it, and why you should check it out.

One sponsor today is Polypane who reimagines the browser as a power tool which helps you build a better website.

Fire hydrant, which helps innovative engineering teams prepare for, respond to, and learn from incidents. The one stop shop to develop and scale world class incident management and content by Kentico. Content is an amazing headless CMS which turns your content management challenges into clean and powerful APIs.

Welcome, Alex. Welcome. How's it going? Thank you. It's very good to be on.

Yeah. Super excited to have you on. We've been Hearing so much about tRPC from everybody, who's tried it, anyone who's tried it, really has nothing but great things to say about it. And We're interested to just get to the bottom of where it fits in the landscape, what it is, high level deep dive. We're gonna be talking all that and More. So first off, do you want to give us just a high level who are you? What are you doing? You know, what's your job?

Yeah. I'm Alex. I've been doing websites since the late nineties and, working professionally as a software engineer for 15 In years or so now, I work at a company called Tola, which is sort of in stealth pre launch Fintech company based in the US.

And, t r c is not my main job, but something that sort of spun out of My own frustrations while building, my own company a few years ago. Nice. So do you use tRPC

at your your your stealth job? Yeah. Exactly. So, yeah, we use it at work as well. Cool. Nice. I guess let's just get into it. High level, what is TRPC?

Yeah. It's funny. I've I've been getting that question for A year and a half now. And, there's no really, like, super short answer to it. But, in I think the easiest way to explain it is sort of like an alternative to REST or GraphQL, where instead of Thinking about, like, endpoints, and APIs, you think instead about functions. So you express your whole back end as functions you wanna call, and you use you use TypeScript to infer the sort of API specification Just by writing functions in the back end, and then you can call them on the front end without an extra fuss, without writing any schema schema definitions or anything like that. And then I've borrowed a lot of concepts from GraphQL. So if you've been if you've been working with GraphQL a lot, you will recognize a lot of different, a lot of similar syntax from working with, like, Apollo or stuff like that. Nice. So is is there, like, a caching layer involved too, or is it just for the queries and functions? So there is a sort of, like, The same caching you'd have in rest, that's what I'd say. So, like, in tRPC, we have the definition of queries and mutations. That's a that's the 2 base types of functions you can call.

And every query, if you use the HTTP adapter, at least, are called over HTTP get. So they can be cached the same way you would do with any REST endpoint, and the mutations are called with post. So that's sort of similar to GraphQL, but A slight difference is that when you do a query, you actually do a get request. So it's quite easy to cache on an HTTP layer.

Yeah. So you don't need that, like, normalized client side cash that you might have in

No. Exactly. So Yeah.

Yeah. With Jumping a bit ahead, but if you use the re s the React client for t r p c, would that's built on top of React Query that Handles all of that to the client side, caching for you. Okay.

Okay. So it's it uses essentially rest. It uses These these functions, none of this is being done by, like, cogeneration or anything like that. Right? Is this Yeah. Is this an instance where what you're doing is defining these functions and behind the scenes, These functions are are doing a fetch call. Like you said, it's just doing a get request somewhere. So, is that how it works? Yeah. Exactly. So

The functions you define are as you said, there's no cogeneration step in, involved, so the client is just Sort of, like, doesn't know anything about the back end at runtime.

You just know it as compile time. So that gives you a lot of, like, art completion and, They're nice red squiggly lines when you thing up. And, the the the requests are then made Based on the sort of link you have defined, the the link the most common link then is the, HTTP. But you can also use WebSockets and stuff for the for the communication between the client and the server? Oh, that's easy. So you can control that communication layer as well? Yeah. Exactly. So it's configurable.

And I've seen some people doing, Adapters for UDP and stuff like that as well. Mhmm.

But myself, I only use the HTTP layer right now. I built a WebSockets layer because I needed it for another product.

And we have support for subscriptions as well,

but I don't use them myself at the moment. Yeah. I I haven't done too much with subscriptions after I left, like, the meatier side of things A while ago, but, Yeah. Yeah. Yeah. It's really great that that it it's available.

Yeah. Media did so many things that were I I know I've talked about a lot on this show, but it's so many things now nowadays that people are starting to do, like like being able to call a function from the Client side that is essentially describing your server side data without having to think about, those those requests. I think that's really that need that you're you're taking that approach because that makes a lot of sense to me To have, just those functions that you wanna call. This is and and correct me if I'm saying anything wrong here because I'm not an expert in this by any means. So One of the things that I've been hearing personally is that it it it gives you a lot of the type safety GraphQL Without having to have all of the extra stuff associated with GraphQL, how how do you, Can you maybe talk a little bit about that type safety and how that works getting types from the server side to client side and how that all Connects. Yeah.

So with GraphQL, you sort of need a few different fakes to wire it up, right? On the back end, you have some sort of, like, GraphQL server, that server generates a GraphQL spec, which is a GraphQL in the GraphQL language. And then we use that spec to then transform that into some sort of type safe client that you need to use in the, on in the browser.

And that is a step we can sorta avoid if both the client and the server are written in the same language. So in this case, We use TypeScript onto both both the client and the server.

And a fun thing you can do in TypeScript is that You don't have to in order to use a type, you don't actually have to export the full runtime type. You can export it as a type. So The the sort of base thing we do in tRPC is that you define your whole back end, and then you just export your whole back end as a type. And then you import that type on the client, which doesn't give you any runtime information, but it gives you, compiled time information that Gives you all this, like, end to end type safety and, auto completion and this really nice thing where you can, like, Command click a function in your front and then jump to it in your back end. You can rename the name of a function. It renames across the across your front and the back end you can rename like an input argument of of a function, and that will cascade throughout your whole application. So you get, like, a lot of, like, power from the Type safety without very without much of the cost of doing it. Yeah. So your editor

is aware of all of the the types across your project. But like you said, the the client side isn't getting any Any code from the server side, essentially.

Yeah. Yeah. So you don't have to worry about using your your node stuff in in a client side environment Enter heavy needs. Yeah. Exactly. Crossover. Nice. And and you don't have to actually declare

types in your back end. You get it for free because The the inference in, TypeScript is so powerful that if you, for instance, declare a comms, Like, you declare a var variable, you put a string in that. TypeScript will know that is that is a string. And if you take that string and put it into a function, you haven't declared it's a string, but you TypeScript know it's a string by you defining it as a string, and you return that in the function.

TypeScript will know that this function will always return a string.

And then if you multiply that Buy a 1,000, put in any other sort of objects.

And then all of that information is already in the compiler in TypeScript to know if your application is running correctly.

All that type of information is can then be used by the client in order to give you a better developer experience.

This episode is sponsored by a new sponsor, which is Polypane.

Now Polypane is a browser that gives you power tools for working on the web. Then I should know because I've been using this thing for quite some time now, and this is a tool that I have really, really loved in my time of using it. Why? Well, Polypane gives you a lot of different things, whether that's multiple pains to really See your site responsibly at different devices. In fact, there's, like, templates for every single type of device. So you can say, alright. What are the devices we're targeting or even what are the sizes and then handful of those visible in 1 fell swoop. You can zoom in and out. You can arrange them so you see them in a special way. It gives you accessibility tools that are just baked in so you can have a little information panel open that's showing you every bit of accessibility issue your site might have. It also gives you great SEO tools, things like OG images for open graph images. So you can preview your open graph images or your Page titles or meta descriptions or any of that directly in the pane there. It's awesome. Not only that, but when you have pains for testing your responsive design. It can keep them all in sync whether you're typing into inputs or scrolling or logging in or any of those aspects.

A polypane sinks across all of the different sizes so you can see exactly what's happening. You don't have to try out the same bit of functionality over and over and over again. Like, I know so many of you do because, honestly, that's how I did it before Polypane existed.

Now there's also some really great web quality tools.

Like in for instance, every time your page refreshes, it's telling you How fast and how slow? And it'll give you a little light at the bottom of each frame to let you see exactly, if this load time was Too long or too or not too short. There's no such thing as too short when it comes to load times, but it gives you a really great visibility into how your site is functioning.

Not only all of that, but it gives you access to dev tools just like you would expect to be able to see your network requests, see your elements tab, Change your styles and so much more.

I I really cannot get into every single one of the amazing features that Polypane has because this thing is next level. So what you wanna do is head on over to polypain.app Forward slash syntax or click the link in the show notes and get started with a 14 day free trial.

If you use the coupon code Syntax 20, you'll get a 20% discount.

When it comes to tools like this, you know, let me tell you. This thing has been Absolutely ruling my life in our new redesign. So check out polypanepolypane.appforward/ Syntax, thank you so much to Polypane for sponsoring.

Am am I correct in saying that this is, helpful or or, possible because of Something called Zod? Is that related?

Zod is part of the equation. So Okay.

XOD is one of the input validation libraries that are compatible with tRPC.

Okay. So you don't need to use XOD to use No. JRP z. Okay. You you can also use Yap or Okay. Deepa Struct and a few others.

But XOD is by far, the best, like, input validation library I know for TypeScript.

And, also, Colin, who create created SOD, also wrote the, like, the very initial Proof of concept of tRPC around 2 years ago that I found, abandoned on GitHub and then took over

And build tRPC from That's that's super interesting. For some reason, I had it in my head that Zod was, like, baked into tRPC. So, that's good to know that you you didn't it's not like a Zod requirement.

Are you personally using Zod? Is that something you're into? I'm curious about it because you seem a little bit early on the ZOD train.

Yeah.

So what I really like about ZOD is that it maps Really well to how TypeScript interfaces and types are decl declared when you declare them.

Things like optionality is a default. Allow like, required is the default, and optionality is Something you have to do extra work for. So, like, when you declare the interface in TypeScript, you have to add the question mark to say that it's a nonrequired.

Similar in SOD, you have to do the dot dot, optional, where in YAP and other libraries, that sort of The in you have the inverse instead, so it's a bit closer to how types TypeScript works. And then it's super powerful in terms of The features, feature set that it allows you to do, the features it allows you to do.

And,

Yeah. Like, I don't I haven't had any issues with it, really. Yeah. I I found it to be pretty neat. We actually use it to, do schemas in our our new back end. And, what I found that's neat about it is there's quite a bit of community around it where, we can transform our Zod schema into a JSON schema for our database validation without having to think about it. Or where did you hear about Zod first? And how did you get down to it so early? Because it it seems like there's a lot of people using it, but at the same time, it's it's kinda still pretty underground.

Yeah. Yeah. I started using it maybe 2 years ago or something.

I was just looking for validation libraries because I've used probably A lot of them, like, and whatever.

And I just found Zod and looked at how it Defined its types, and my biggest selling point was this, like, required by default, rather than being optional, which was something that's always annoyed me where, like, in any other spec, you have to define you have to do, like, string dot required Where I think, like,

it's a swing. And if you wanted to do something else, you should add something else. Yeah. Yeah. Yeah. That's kind of I mean, that and that aligns directly with TypeScript words. If you give something a type, then it is that type, and you have to say if it's Possibly undefined or no. Right? You have to directly say that. And that definitely, like I think that works really well as somebody you know, I've been working a long time in In GraphQL, I always found the, like, non null GraphQL system to be very odd,

personally or or Kind of difficult to work around it. Yeah. You you missed to add that bang and then Yeah.