Zod and tRPC for the Rest of Us with Tejas Kumar
===

Paul: [00:00:00] Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. Tried for free@logrocket.com today. My name is Paul and joined with us is Tja Kumar. He's an international keynote speaker, angel investor, advisor, mentor, 

we've had him on the podcast before and we've talked about things like TypeScript, setting up projects, building teams, and building great end experiences for our users. And today we're gonna be talking about Zod and T R P C for the rest of us, his talk that he recently gave. Welcome back to the podcast stages.

Tejas: What's up? It's good to be here.

Paul: So people probably know who you are cuz you've been on a few times. But for those who are tuning in for their first time how did you step into the world of development? How did you step into doing podcasts with us and what are you into right now?

Tejas: I stepped into the world of development. By, by chance. Yeah I wrote my first line of code when I was [00:01:00] eight years old after playing a lot of Prince of Persia on Windows 3.1, and I was like, yeah. And then I'm like, I wonder how this is made. And I was like, oh, cool.

And that's my foray into tech and, web followed mainly because the feedback loop with JavaScript is so easy. Like you just open the console and you can just like window dot alert. . And the rest is history. What I'm really excited about these days is the work being done around developer experience.

I think especially from the front end world, like from the likes of, TypeScript and Versal and all of the things in this area. The DX is just like increasing in quality exponentially year on year. And I'm so here for it.

Paul: I feel like a lot of times that is the direction of the stuff we end up talking about. For the last 20 or 30 years we've been solving tech, pushing the technological boundary. How fast can we load? How small can we get bundles? And now we're talking about solving more human related issues.

Developer experience, team, organization, and I [00:02:00] mean your talk. This is kind of like in line with it. Your talk like Zod and D R P C. For the rest of us, this is DX related. Would you say

Tejas: I would say but I'm glad you bring this up because I feel like it's DX related, but in service of UX and, I spend a lot of time on social media and what I see is a lot of. Discourse on DX that doesn't really have a direct impact on ux and that's what I'm not here for. Like we often, I feel like sometimes, and I'm guilty of this too enter debates and discussions around things that your end users probably wouldn't even notice.

And I think those I'm weary of, but yeah, like Zod and T R PC I think provide good DX by way of auto completion and a lot of developer conveniences while also adding. A lot of value to UX such that they literally like in the browser at runtime will add validation steps for your users.

So it's this awesome thing where it's not just DX wins, but also UX wins. And that's what I'm really excited about. Like things that just feel good to me as a developer [00:03:00] are awesome. Things that feel good to me as a developer, but then don't really impact my users less. Awesome. But things that combine both, oh my gosh, that's the gold.

Paul: Now you mentor and, like lead workshops and like right before this podcast you lamented to us about like having a long and it involved deep process going over like react internals and stuff. So do you find. That and T R P C lend themselves very well to being like a silver bullet when teams are facing issues and you're going to advise 'em and you're in these meetings and you're saying, listen, like I have this thing, this technology in the back of my head, I'm sure it can help this process a lot.

Is that a silver bullet for you that we're gonna be digging into today?

Tejas: Yeah, I don't think it's a silver bullet. I'm very skeptical of silver bullets, but it, it's, definitely. A very valuable tool for sure, because I feel like, there's a lot of praise and joy around TypeScript. And TypeScript is, nowadays when I hear like people hate on TypeScript and say JavaScript is better I don't know what to do with [00:04:00] myself, right?

I've got years of lived experience where typos are just a thing of the, I don't think about typos anymore. I don't think about If the number is not a number, like all of these things are solved problems I, I use my auto completion and I trust myself a lot more thanks to TypeScript.

So TypeScript is amazing, but I still feel like TypeScript at, for users at least solves half the problem. What I mean by that is TypeScript doesn't necessarily solve DX plus ux, where UX is end user experience. But tight Strip does solve dx. I feel like the missing piece of TypeScript is where there's IO boundaries that are out of Typescripts visible scope, where TypeScript has no idea, like what's gonna come to you over the network or when if you read from disc, like TypeScript has no idea of knowing what's coming.

And that's where things break down. Or in the case of like form inputs, right? TypeScript has no idea what a user is gonna type and users often will try and type stuff that they shouldn't. Right? I once did a talk recently at React [00:05:00] Miami, where I made the mistake of creating a collaborative like everybody type a CSS rule in real time and we will have a nice time and I expected people to go comic san or make the text read or something.

But somebody did display none and then nobody had access to anything. People like to just enter data that maybe they should. And so TypeScript falls apart at dynamic boundaries like that disc io, network io user input. And so as great as it is for dx, I feel like it falls apart in, in user land.

But this is where Zod shows up and it's like, hey we complete the picture, we close the loop. We make TypeScript robust on both sides of the spectrum. And so I think that's what's really exciting about it.

Paul: Could you talk to me a little bit about what is Zod and is T R P C is not Zod? Yeah. That's a separate thing. And could we rope a definition for T R P C into the definition for Zod?

Tejas: Yeah, absolutely. Soza is Superman's arch.

Paul: It, so it sounds you, I, you could fool some people who [00:06:00] aren't in the space of that one, a super villain named Zod. It totally works.

Tejas: No it actually is from the DC universe. It's 

like 

super. 

Paul: I'm not a DC guy, 

Tejas: yeah, me neither. Anyway, but so Zod is indeed from the DC universe, a villain, but in the case of software Zod is a, the validation library that , in a very basic sense, will you, you give it a schema and you say, I have.

These keys , in a key value pair, like an object. And this key is supposed to be this type and it has even better helpers like this type, not just the number, but an optional number or a number within this range or et cetera. So you just give it a schema and then it will validate that schema against any input you give it.

That's what Zod does. It's just a validator. T R P C uses Zod. As a validator for its work. And so you might ask, okay, what is T PC's work? T RRP C stands for TypeScript Remote Procedure Call draws a lot of inspiration from G R P C, which we probably is scoped for another podcast, but t r PC is a communication framework between server [00:07:00] and client.

Think of GraphQL, right? GraphQL the same. It's an RPC based approach, meaning a remote procedure call based approach that establishes a contract between server and client. In the case of GraphQL, this contract is described by the GraphQL SDL or the schema definition language. T r PC has the advantage of just being TypeScript, so there, there's no extra language specification to follow.

T R P C combines a router. Procedures such that a given route calls a given procedure with predefined input and output schemas. So like a simple example is a greet, a greeter app, a greeting endpoint where you have a route slash greet. It accepts over HTB post, it accepts a body of name is the key, and the value can be Paul and that schema of the input type.

Is something that Zod enforces both on the server and on the client. So that's the synergy between Zod and t r pc. So Zod is this validation [00:08:00] library that ensures objects, numbers, any type is what you expect it to be. And T r PC uses Zod to make sure that your H T T P data across the network boundary is what it's supposed to be.

Paul: Now, do you have to use. T R P C or is that the suggested

Tejas: Yeah, that's a really good question. As far as I've been able to use them in production, yes, you have to use Zod and trp. It literally, like in terms of the types it expects Zod schemas specifically now because everything's just an object. You could have an object that implements that interface.

You know what I'm saying? You just have an object that, but it is very closely coupled with Zod.

Paul: So T R P C, just to be clear, it's like a server. We're talking about stitching together routers to create an API or some interface.

Tejas: It's not a server. So that's a good question. That's a really good question. It's a server and a client library. So when you import it, you import from TPC slash server on the server side and TPC slash client on the client side. The [00:09:00] cool thing is it shares code. So the router itself 

it can be built around a type, a static type that you define, you say, type route is this, inputs are these outputs, are these, et cetera. And then you can take that type, which is just a type and use it on the server implementation and in the client implementation. So that's the thing. So it shares type across both sides.

But it has two separate packages, one for the server, one for the client. But the types are common. The big advantage as well, I mean you didn't ask, but I assume you probably will is. There's no code generation step. So in the case of GraphQL it supports this thing called an introspection schema, where you can introspect a GraphQL server and look at all of its types of queries and mutations and inputs and outputs.

And traditionally like Apollo and a lot of tools use this introspection schema to derive types. It would literally, say it would generate static TypeScript types from that. The problem with that, If you forget to run kogen [00:10:00] or maybe you go on vacation and come back and, in any case your local static types can be out of sync with the server's introspection schema.

This is mitigated with t R PC because everything is just type first. It's type first. It's not type generated, and that's the benefit.

Paul: I think it's interesting that you used the word mitigated too, because I'm assuming this means that your client, whenever you import it needs to be imported from the correct up-to-date source, to reflect those correct types. So there is still the possibility of drift, but it's managed by hopefully your package manager.

Tejas: And hopefully you've got a nice monorepo and everything's linked properly and yeah there's a lot. I've heard someone say turbo repo plus TRP C plus type three plus , is. The thing, , I think it, it varies based on what level your team's comfortable with working on.

But yeah, it is mitigated. It's not solved entirely.

Paul: Would you say that T R P C if we were to make like a poster child quote for it, it's reduce errors in your app.[00:11:00] 

Tejas: Yeah. I think that's, I think I, the only problem I have with that statement is that's pretty nebulous, right? Errors where

Paul: it is. It is nebulous. Yeah.

Tejas: I think. Like we could refine the scope a little bit to say reduce network errors in your app For sure. I think that's a good one because also t r PC doesn't let you write any network handlers yourself.

This is the great thing. It has strong opinions that it enforces. So for example, we use this greet endpoint earlier. You just literally describe the input, the output, and the business logic. But in terms of returning a status code or like setting cash headers or whatever it manages as much of that stuff as it can.

And you can of course take some control back, but it typically handles all of that for you out of the box. So it's pretty opinionated and because it's opinionated, you can move faster.

Paul: Sort of Like on GraphQL, you know, they have an opinion about the cash.

Tejas: Yeah. Yeah. 

Paul: how are, yeah. Okay. So do you feel like it follows a similar mojo to the GraphQL and where they're drawn? That line[00:12:00] 

Tejas: Yeah. Yes. The only thing is GraphQL is, GraphQL itself. If you think about just GraphQL and isolation it's nothing, it's not a cl that's maybe a bit harsh.

Paul: that's harsh that this thing, 

Tejas: I misspoke. What I meant was it's not a server, it's not a client. It's not any implementation, it's just a specification. And I think that's the difference, right? TR PC is like a set of libraries and it's concrete. Whereas the GraphQL itself is just an abstract specification.

Paul: I'm gonna take a moment here to just remind our listeners if we're, if you want to reduce network errors, you could do things like T R P C. You can also check out. Log rocket, which you know the whole point of the product is to help you find errors, quickly reduce that surface error and bring them to your developer team as quick as possible.

So go to logra.com today to check it out for free. If we're turning back to. Talking about what T R P C wins here , it reduces network [00:13:00] errors.

There's a lot of frameworks today that kind of are poking a similar bears. So like remix, if you're using remix or I'm thinking like Astro. you know, you can define these loaders and you don't have to worry about how you're serializing data as much. You need to make sure it's serializable, but you don't need to like, worry about passing things along.

Do you find that this step out of the network plane, so to speak and how we're engineering around or trying to be creative about how we're transferring data is changing the structure of the web development team as a whole?

Tejas: Oh, that's such an excellent question. Wow. I feel honored just. Hearing this question, I think absolutely it is, right? Because if we look at the history of the web development team, so to speak I'd say 20 years ago, it was just like one type of position. Webmaster. That's it. What does that even mean, right?

You just, you have somebody who works with, what does it, lamp or Wamp or mamp Linux, Apache, MySQL, php, and this is just one person just doing all this stuff. And usually leaving apps [00:14:00] susceptible to things like SQL injections, cuz they're probably not security experts. And like I, I've been there, and then we got this deviation of front end and backend and senior front end and backend was, I still think it's somewhat nebulous because , I see jobs for like backend engineer, but then there's also jobs for DevOps engineer. So it's, it's a little bit nebulous to me. But yes, I think that's the team we've had. But I think introducing all of this, I'd say server side complexity to what is otherwise front endy stuff like next JS and so on, does augment the team structure and adds a new meaning, I would say, to full stack developer as a job description.

Because it even adds like a piece onto the stack, right? Like it adds um, This component of the bff the backend for the front end that is a relatively new, I would say, concept that exists just because of like serverless functions and next jss API routes and things like that. So yeah, it definitely does augment the team structure, I'd say for the better cuz it, I feel like it gives more categories of jobs and therefore more jobs and therefore more [00:15:00] inclusion and therefore more people get into tech and I feel like it's good.

I haven't seen anything negative from it.

Paul: It reminds me of, I remember back in history class where we learned about how homo sapiens to specialize and that's what pushed the envelope forward. Cuz you could get the expert potter and the expert like. and so here. When you say augment team structure, to me it also feels like the team grows a little bit.

Cause you don't have one guy, we have people, several individuals, all contributing. But it allows people to silo and silo's usually like a bad term. But here it almost feels like it's an efficiency boost because I don't have to worry about some crazy stuff going on in, in the backend for some service that I'm, I don't work on.

Tejas: I think it's the right direction because I hosted a episode of, of this podcast actually with Mateo Collina who mentioned in a dream team, in an ideal team , you want one person working on one piece of your tech infrastructure. So you want, for example, if you're like a big e-commerce thing, you [00:16:00] probably want one person in charge of the checkout experience and one person in charge of the single product page, et cetera.

And I think we're getting there and I think that's a very good thing because we also allow people to do what they really like. Instead of having generalists. But I think there's an interesting question in there, Paul about, people getting into tech, right? What's the preferred route?

Is the preferred route to be as specialized as possible? That is to have a very deep knowledge in something, or is the route preferred to be more of a generalist and kinda have a broad, but not as deep scoping of talent? I don't know.

Paul: Yeah. And I don't know either cuz you're gonna get arguments that sound correct from both ends of the spectrum 

Tejas: Yeah. 

Paul: of all trades and the people who can do things that nobody else can do on your team. You're like, no, we can never get rid of that guy nobody can do what he can do. So

Tejas: Yeah.

Paul: do you feel like these technologies are raising the base level of complexity?

Cuz you mentioned like this is like another layer to the stack, right? It also feels like there's the [00:17:00] junior dev and grandma master dev separation almost became like a thicker, bold line on that cuz you either know all the layers of the stack or you work on , one of those ends.

Tejas: Yeah, but I think like your question was, is it raising the base? I don't think it's raising the base. I think the base is always html, CSS and JavaScript. And I think for those of us in the industry who have been in the industry for a long time, we have a responsibility to maintain that.

That's the base. I would be very scared of a moving base because that then means, Not everybody gets to participate because it becomes more and more esoteric. I think a good example of this is AI and machine learning, right? , like for me Paul, I've worked in many roles, I've been a front-end backend, DevOps, whatever.

I've never worked as a data scientist and I feel like it's too late for me because I feel like machine learning and AI has moved that base into a very deeply mathematical realm that I would struggle to catch up to. And I hope that never happens to like web development and so I think, I dunno, I feel a sense of responsibility to make [00:18:00] sure the base stays html, css, and JavaScript.

Paul: I think some of the fear some of us might feel right now as web developers with the AI stuff is that moving base cuz you can see the potential for that base to be moved.

Tejas: Yeah, definitely. So there's I don't know if y'all ever had Lori Boss on the podcast, but I would highly recommend him as a guest because he is this person who works at Netlify as a data analyst and like he is, Like deep in the package up JSONs of thousands and thousands of websites.

And his job is to analyze trends and he did a talk recently at Render ATL earlier this month making predictions based on all of this data. And his big prediction, the video is probably live by now, but his prediction is HTML and CSS is the base that's about to move because. Things like chat gpt and other large language models are very capable of just making HTML pages that people fine tune.

So it's due for an upgrade and I agree and it kind of scares me

Paul: And we as humans, there's [00:19:00] some inputs and mediums of communication that are just better done visually and we are getting really good wissy wig editors out. You can get a lot done with clicking and dragging. Have to be in agreement there.

Tejas: Yeah. Although I do have like reservations about CMSs and headless CMSs specifically, that's just me as a developer, right? Like I, I feel a lot more control when I can like actually write the code myself and I feel restricted by things that headless CMS let me do and don't let me do.

And I understand the value for people who don't know the code and stuff like that. But yeah, so I think tying it back to the moving base, I feel like even if the base moves, I think some of us would still just prefer to write the things ourselves because we know it's automatic cars are the thing now, but a lot of people will still prefer stick shift because it gives them a certain, feeling.

I think that'll stay for a little while.

Paul: Turning our attention back to Zod and T R P C a little bit , I know there's a lot of crazy stuff that people can do with Zod. They have this refined method. You can use, they [00:20:00] have all sorts of combinations and transformations. I've personally have used refine to do something like, you can take an input and feed it through any reg expression you might want.

Could you talk to us a little bit about maybe some anxieties or apprehensions the team has had about oh, there's this one library that can validate everything. maybe they didn't think it could satisfy their need and how some of these higher level mechanics or components have allowed that applicationary interface really to blossom and be what it could be.

Tejas: Yeah. That's a really good question. If we think before Zod I can't remember. I. Like a really solid JavaScript library. There was Joy, j o I, but there wasn't such a validator that was as extensive. I feel like as Azad is, and this refined step you talk about, I think is a huge evidence of that.

Like you can literally, first of all, Zod exposes a number of methods already to validate on, for example, you have z.email, which.

[00:21:00] Yeah, but email rejects are super hard to write properly, right? And they're usually very large and so on. But the ZO team is just you know what? We'll give you one here.

But because of the nature of email and maybe you have some type of on-prem thing with different types of e I don't know you, you may want to fine tune that. You can literally just like dot refine and specify your own validation rules. So they give you conveniences and they also give you escape hatches.

And I think. That combination is really powerful. But I, I kind of find it hard to wrap my head around. That doesn't even stop there. But it allows you to read, parse, validate, and then change and then transform types. And I think that's also fascinating. I've used this for like HTML elements when you have an input type number.

And you want to validate that it's, like greater than a certain range or something with Zod. HTML gives you the value as a string and you want it to be a number. So you can use, in this case, Z dot transform and pars [00:22:00] floated essentially. But last I checked, and this is maybe an issue, I should open Enzo.

The types from transform Enzo don't reflect. When you do type of a z infer if you transform something from a string to a number, it's still a string in the static way,

I think. Yeah. But the fact that it does all of this, I think makes it very powerful For sure.

Paul: So we could almost paint the picture of if you're anxious about, oh, I have some crazy data, or there's I'm not sure how we're gonna be flexible enough. We could probably express your need in your A p I. Using the powers of Zad and, consequently, then we could rope it into a T R P C interface.

Tejas: Yeah. 

Paul: Do you find that people are plugging in the server side of T R P C and in the folks you've been mentoring and consulting for like in existing projects? Is it a rewrite? Is it a Hey, we're gonna take to the next JS hand learn, throw in T R P C route

On our server

Tejas: yeah, that's a really good question. I though, from what I've seen with T r pc, it's pretty incrementally adoptable. And , we talked about how there's like t r PC [00:23:00] server, t r, PC client. But there's also, we didn't talk about this and I think it's pretty important is that t r PC has adapters as well.

And adapters allow T R P C to work congruently with existing solutions. So there's literally, there's a view three adapter. There's a next, there's an S W R S W R being like Elle's answer to data fetching for react. There's a remix adapter. There's a adapter. There's just a bunch of different adapters.

Where T R P C just brings itself to these things. And so in the case of like incrementally adopting tpc, you could easily have a few next JS handlers kind of rogue, so to speak, unmanaged by t r pc. And then you could have a few with t r pc, then you can like slowly bring them together. So yeah, you know what?

I don't see Paul, that's really interesting. I don't see a lot of anxiety or apprehension around Zod. And I think that's interesting because. People want validators, they want the guarantees of safety across the [00:24:00] network boundary. And it's one of those things where the default is to not have it, you know what I'm saying?

So , there isn't so much anxiety of adding it because it's going to be good. And then if we don't add it, or if it somehow doesn't work and we need to remove it, then we're just back to the default. We're not any worse than when we started, if that makes sense. Yeah, so it's this thing where people are like, yeah, let's add it.

And then if it doesn't fit a certain use case, that's fine. And what I've seen with a lot of teams I've worked with on this is there's a strong embracing of the open source nature as well. So like, if it doesn't support a certain use case of ours, we'll just contribute it back via fork. 

Paul: So if teams wanted to start integrating or \ . Incrementally, like we, we just mentioned, like adopting T R P C Head over to the t r PC Docs page. Attp tpc.io/docs if you wanna check them out.

Tejas: Yeah. It'll be in the show notes. I wanna shout out Christopher ish. He. On Twitter, I believe it's handled as something wacky and it's probably in the show notes, but C C C C J j j j e e e e underscore, [00:25:00] I don't know why, but , he is one of the maintainers and I gave him a really hard time.

Cuz I, I started exploring T R P C in February. And it was not well documented. It was pretty hard to get, mainly because, so T R P C revolves around these concepts of routes. And pro proceed. It's rrp C, right? So routes and procedures and as well inputs and outputs that you validate with Zod.

But with t r pc, there's a lot of concepts that you need to understand. You need to understand routes. You need to understand procedures, you need to understand how they fit together and so on. And I told him in February, I was like, bro, this is like Angular tube, or Angular. I dunno what angular was on like three, I don't know.

But because I explained to him that there's a lot of concept overload and each concept. Wasn't at the time very clearly explained especially to like people coming from like react quarry, and since then . It's undergone some tremendous development and now I feel like having read the docs recently myself it's to me at least way more obvious than it was.

And I hope it's more welcoming to [00:26:00] people. Just a shout out, Christopher Erlich and team.

Paul: Thank you Christopher Cuz docs are huge if you don't have the docs and there are a lot of like concepts to understand. But I would say also, if you're coming from a GraphQL, Area it's more familiar or like you've been harping on it's r pc, this is just r pc and having the verbiage of oh, I know what a procedure is.

I have the idea of running a a query on the, on your server. It feels a little familiar.

Tejas: Yes, but I came from GraphQL. And the thing that threw me was, so GraphQL is arguably simpler in this way, that there's just one route. It's like slash GraphQL. Everything's on slash GraphQL. This one endpoint T r PC has multiple routes that you can call remotely. And it even exports a router, like a full on router.

And I was like, why? And in the beginning as I was learning, I was like, oh, do I need to use express for routes and then invoke them with, so I didn't, the boundary between the router and the effectively the procedure caller [00:27:00] right. Was not very clear. Mainly , because GraphQL doesn't have this concept of routes.

Everything's just on one route, so

Paul: It's, yeah, T R P C is like one layer up. From where graph goes. you have to think about that structure a little bit.

Tejas: Yes. Yes. And also the conventions. So you have to use the client with it. And this is also maybe a criticism of c r pc. You cannot comfortably anyway query t r pc A T r PC server without using the t r PC client. What I mean by that is if you have a get route it expects its paras.

Along the query string in some format that the client knows really well. But if you wanted to like curl that from a co command line or something, , at least in the beginning, it's not going to be obvious. And then once you read the docs and learn, you're like, oh, okay, so this parameter that I send over the network and so on, but.

The client has strong opinions about the server, and the server has strong opinions about the client, and these two are very coupled by design. But it's just a caveat that if you're trying to query from something other than the client, you'll need to do a little bit more 

brain work. 

Paul: But you [00:28:00] can do it.

Tejas: Of course. Yeah.

It's 

just, 

Paul: you're right. There are gonna be people listening who think oh man, if I can't test this with postman you can,

Tejas: yeah. Yeah. 

Paul: It's still httv under the hood. You can send a request over.

uh, Sot are you like writing about T R P C Inza?

Is this like in your current. Purview of your week to week 

projects you're working on. 

Tejas: that's a, good question. So I did this talk at Canary sgs about it because at that point in time, part of my job is to just be very in the community. And I am, I am, I'm pretty deep in the community. I've got my ear to the ground. I'm listening to what people want, they're talking about what they're interested in.

And there was just a lot of questions about Zod and tpc. What is it? How do they fit together? Why should I use it? And so on. And at the same time de Loafs, the organizer of Canary Js asked me, he was like, Hey, can you do a talk at my conference? I was like, wait, are you asking me to visit the Canary Islands?

And I was like, course man. And so he was like, what do you wanna talk about? And I was like, everybody's been asking about this. So I figure I can make it clear. That's why. [00:29:00] Now am I writing about Zod and stuff every day? No. But I do use them and I know the place for them. And this comes in handy in discussing with the community about solutions and things like that.

I think it's important also that I share one thing that I heard from the community that was a real pain point and I was able to solve it just again, cuz I've got my ear to the ground and so on, which is someone came to me after my talk right. And asked me a really good question. So they're using GraphQL not T R P C.

And they want to use Zod to validate inputs to their GraphQL mutations. So what t r PC does. They want that, but with GraphQL. And we spent a lot of time kind of thinking about how to go about this because what you ideally want to do is take your GraphQL schema and have a TypeScript type

and then convert that into a ZO schema automatically, of course. So basically generate Zod schemas on the fly [00:30:00] and keep them in sync somehow. That was a problem we were faced with. And I said, this is what we should do. How do we do it? And we found a solution. And the solution is a, is an open source library.

That is pretty awesome. Cause Zod will give you for free TypeScript types, right? So you define your Zod schema. Then you can derive TypeScript types from that with one line right type equals Z infer type of zsa, the one line. And you get TypeScript types for free from a ZD schema. But what you don't get is zo from TypeScript.

So it goes one way, it goes Zo two TypeScript, but you cannot automatically turn TypeScript types into Zod schemas that you may want to do. If you want runtime validation from types that you've already written or types that you've generated from GraphQL uh, schema definition language. So we figured this is what we need.

And I was like, I bet there's something you can npm install that does this. Turns out there's a library called literally ts Zod ts dash two dash Zod and it closes the loop and it's by a [00:31:00] really good friend of mine called Fabian. He's one of the most talented type sport engineers I know.

And he wrote this, and I think , this has been missing for a long time. Cuz now you get to use Zod, even if you're using GraphQL code Jen and things like that. I think it enables a lot of safety.

Paul: We got the other way going other direction. Do you think this is gonna get roped into the core library for zd?

, or there's plans for that.

Tejas: I don't think it can because , I think it's almost like a C L I that.

Paul: Gotcha. Okay.

Tejas: Yeah. You give it a TypeScript file and it converts the types from there to schema and then it outputs. It generates Zod schemas for you.

Paul: Taja, it has been a great time talking about TYPESCRIPTS and T R P C and Zod. In our last episode, we talked about Zod a little bit, got getting into the details, and now we're talking about how we could use it with T R P C to actually do some damage 

Tejas: Yeah. 

Paul: in, the best way. 

Tejas: To actually prevent some damage.

Paul: Yeah, to actually prevent the damage. That's what we want. If people wanted to keep up to date with you , you're on Twitter, right?

Tejas: Yeah. That's twitter.com/tas kumar [00:32:00] underscore. And on YouTube youtube.com/at TAs K.

Paul: Kt, thank you for your time. It was a pleasure.

Tejas: It's been a pleasure, Paul, as always.