Sean:
Hi and welcome to PodRocket. I'm Sean, and with us today is Chris Bautista or Trash, who's a senior software engineer at Netflix, and recently spoke at Next JS Conf about making typesafe APIs easy with tRPC. So welcome to the podcast, Trash.

Chris Bautista:
Hey, hey, happy to be here.

Sean:
Yeah, happy to have you join us. And before we get started, I feel like for those who might not have heard of you yet, can you tell us what Trash Dev is and then why you chose that as the name?

Chris Bautista:
Yeah, so I think when Covid first started and everyone started becoming remote, I wanted to be able to talk to people within my community so I reached out to the software in depth Twitch category to kind of put myself out there and talk to like minds, but I couldn't think of a username, so I suffer from insane imposter syndrome. So I was like, "Okay, how can I lower the expectations as much as possible so then when people come in they won't judge me?" So I chose Trash Dev so then when they come in, they're like, well, okay, I either exceed their expectations or I meet their expectations. There's really no way I can fail. It's kind of like a win-win situation. So I kind of shielded myself from just feeling really bad about myself by using this name and it kind of just end up sticking. And now everyone literally just knows me by Trash. I don't know if that's a good thing or bad thing, but I don't know. I kind of enjoy it.

Sean:
Yeah, I like it. You'll always exceed expectations. My guess was that it was like Trash Dev is a moniker to lower the barrier of entry into development. But yeah, I think it's a funny name. And so when did you start doing the online stuff on Discord and Twitch? I guess what is your journey as a developer up to this point?

Chris Bautista:
Yeah, so I look 14, but I'm really old. So everyone thinks I'm pretty new to this space, but I've been around. So do you want me to go on my whole journey from literally soup to nuts kind of deal?

Sean:
Yeah, I'd be curious to hear it.

Chris Bautista:
Yeah, so when I graduated college way back when, I never wanted to be a developer. I didn't really go to school for computer science. I kind of had a general business degree, but then I realized all my friends around me that graduated the same time me were getting jobs and I was kind of just sitting there. But I took one or two programing classes in college and I was like, "Man, I got to find a job." I went on Craigslist and there was a job that literally just said programmer, and I clicked it and then I went to do an interview and I had to write two if statements and I then I got the job. I was like, "I guess I'm a programmer now," and I was writing... This wasn't that long ago, but I was doing mainframe programming. So I did like AS/400 COBOL, Fortran, the stuff you see in programming books from way back when.
And I was kind of stuck in that world for a year. And then I realized, "Oh man, this is not cutting edge stuff." So then I transitioned to doing .NET for a while and I was really into databases, so I was like a PSQL developer for a little bit. I was super into just writing queries and doing a bunch of crazy stuff like that. But I was in the backend space for a while. So I went from C Sharp to Java, and then I was at some agency and I was sitting next to a front end developer and I was like, "What are you doing?" And he was like, "Just pixel pushing. Making the designs all nice," and I was like, "That looks so much fun. I'm literally just looking at code and that's like all I see, I don't really get any feedback, no one really knows what I'm doing."
So I kind of started eating lunch with the JavaScripts people and I think through those lunch breaks I was like, "Man, I kind of want to learn JavaScript." I had no idea what it was. They were using jQuery because this is back in the grunt and gulp days. And I was like, "Man, what do these tools even mean?" It was so confusing. So then from that point on, I kind of dove into the front end realm, but then I was kind of like what you would call full stacky and not really true full stack, but I was doing a lot of C Sharp, but I was also doing a bunch of front end work. And then I'm been slowly transitioning to mainly the front end, but I still will do backend work as well just because that's kind of part of my roots. And that kind of led me to where I was today.
I think if it wasn't for JavaScript I became so passionate about it. I don't think I would be where I am today because that's pretty much what I do at Netflix. I'm a UI engineer here as well. And I don't think without me truly loving the work, because to be honest as a backend engineer was, it was just a job. I was kind of just going through the motions. I was like, "Okay, yeah. I get a paycheck. I need that to live," but then when I found the front end world, I was like, "Man, I actually like this," so then I kind of... When you like something, you tend to go all in on it. And there's that cliche thing, if you love what you do, it's not work. I wouldn't say it's to that extent, but I truly enjoy the space and that's kind of how I landed where I am now.

Sean:
Awesome. Yeah. So when you say you've been all over the stack, you really mean it with the mainframe experience? That's pretty interesting.

Chris Bautista:
Yeah. Whenever people see... Sometimes I'll go over all the languages I've done in the past. They're like, "What is this? It's an encyclopedia of where you've been." So yeah, it's interesting for sure.

Sean:
So yeah, getting into the front end, like you said in the grunt and gulp days, how do you feel about how the ecosystem has changed up to now because it has just seen so much change?

Chris Bautista:
I mean, tool fatigue is real. There's so many things going on in this space. Every day there's a new framework. Every day someone's rewriting how to do bundling or something. So for me it does get kind of overwhelming but it's really up to you to ignore that noise. A lot of people see the shiny toy syndrome or whatever you call it where they just reach for everything. I'm kind of like, "This works for me, I have my set of tools until it stops serving its purpose or it doesn't do it well, then I'll go reach for something else." But I think it's a lot more exciting than the backend space in my opinion, just because it's always evolving. But that can be seen as good and bad. But yeah, I don't know. There's never a shortage of drama in the front end world.

Sean:
There's always a lot to learn. But I do feel that some of the new tools and frameworks that are coming out feel more mature and that potentially the changes will be more long lasting. I think Next.js is a really good example where it does so much and I don't really think of that many other tools I need to pull in with it to use. I think the API routes in particular are one thing that I found really powerful. They just let you go full stack just by using this JavaScript library. And yeah, I guess so how have you felt about using Next?

Chris Bautista:
Yeah, Next was great. To be honest. I don't use Next anymore in my day job. I was using it previously, but I do use it on a lot of personal projects. But I mean Next.js, it gives you superpowers, and your productivity kind of skyrockets, right? Because like you said, with API routes you're pretty much full stack. You don't have to go set up your own express server or something. You kind of just make a file in this directory and then you can just do what you want and you just mindlessly code in it, not without any consequences, but just the barrier to entry to do backend things is just not there anymore.
People that are making eight prior routes don't even realize it's like backend code because it just doesn't feel like it. It just feels like another JavaScript file in your file structure to let you do things. So because of that, it just has enabled so many people to do so many cool things. Way back in the day, to make a full stack application, you kind of had to go through this whole song and dance to get a backend set up, get your friend in to talk to it. Now it's just like right, "It's going to make a file and type some code and then boom, I'm there." So it's amazing.

Sean:
Yeah, there's just one command to get it running locally. You don't have to worry about, "Okay, is my front end dev server running? Is the back end dev server running?" So it feels really convenient in that way. And you were more specifically talking about the typesafe APIs. So what are some solutions out there today that provide typesafe APIs?

Chris Bautista:
So there's quite a few and I mentioned them and I talk. So one was Open API. If anyone is not familiar with Open API, you probably might have heard of Swagger. And there's also something like GraphQL Codegen, which I use at my day job. So essentially what those do, they basically just introspect your schema and then they just spit out all these types for you, and that's kind of how you get that type safety. And I think those solutions are great. I don't know, do you have any experience or have you used any of these co-generation type solutions?

Sean:
Yeah, at Log Rocket we use GraphQL Codegen as well, so defining schema and it kind of spits out the types you need. So that I have found to be pretty convenient but I haven't explored too many other options out there.

Chris Bautista:
Yeah, same here. The API stuff, I'm aware of it, I don't have professional experience with it, but I have used Relay and Codegen with Apollo as well. And to be honest, those work pretty well. I don't know if you've had any negative experiences, but it's pretty straightforward. You just generate this and then you get these hooks you can use to consume in your app and they're very convenient to be honest.

Sean:
I think that having, at least in our GraphQL Codegen set up, there's a new build steps regenerate the types. But of course I think that people can maybe work that more seamlessly than I have into their local development experience where they're not kind of reloading the types from [inaudible 00:10:15] manually. But yeah. So what is the tRPC typesafe API? Do you think that's a new challenger that's going to win over against the GraphQL Codegen?

Chris Bautista:
I don't know if they're direct competitors because it's kind of like saying is GraphQL competitor to tRPC, which I don't think that's the case. GraphQL has its purposes and I know Alex who created tRPC is a huge GraphQL advocate, but tRPC does give you an alternative way to achieve this typesafety type things. Usually I've talked to some people when they reach for GraphQL, their main reason is for the typesafety because they want the GraphQL Codegen, not necessarily because they graph QL. With tRPC, that gives you a more lightweight alternative to achieve the same results. And I think recently tRPC just has been taking off. The stars have just been rising like crazy. We've been seeing a lot more activity in Discord and a lot more adoption because people have seen how quick you can set this up and then just get the immediate type safety and the developer experience is just amazing. And I think that's why it's just blowing up right now at the moment.

Sean:
Yeah. Is it just that it's easier to integrate interior existing application? Is it incrementally adoptable or is it doesn't have all of the baggage that comes with bringing GraphQL, which might involve kind of migrating from your more electrician like HTP rest API to GraphQL?

Chris Bautista:
So I think migration path for if you go from GraphQL to tRPC would be easy. I think we recommend against it. If you're on GraphQL, you should probably just stay there. If you already have that typesafety going on, I don't know if the juice is worth the squeeze or a squeeze is worth it. I don't know what I was about to say there, something like that. I totally messed that up. But when you think about it, tRPC has these resolver functions and your resolver functions are literally a function that returns something. So assuming your existing backend is just made up of functions, they just say, "Hey, this function goes and gets this data source," you can literally just copy and paste that code and put it in your resolver function.
So in my mind, I personally haven't done a full migration from a traditional arrest set up to tRPC, but through conversations I've seen people on Discord talking about migrations. It's literally a matter of them copy and pasting that logic into this resolver function. However, [inaudible 00:12:53] also has made a code mod. So if you were on v9, currently we're on v10 or we just released v10 RC, we have a code mod that kind of migrates you there.

Sean:
Oh awesome. Yeah, that sounds super convenient. So there's help out there online if you're looking to migrate.

Chris Bautista:
For sure, for sure.

Sean:
Awesome. Yeah, so that is in terms of the inputs then, are those just normal TypeScript types or is there kind of a specific syntax API and tRPC for setting up those inputs to your routes?

Chris Bautista:
So the inputs are effectively your contract to your endpoint. So we use that. You don't have to use that. You could use something like YEP. If you're not familiar with Zod, it's pretty much just a validator I think most commonly used with forms. But yeah, so obviously not all endpoints necessarily need inputs, but when you do need input, say you need to send an ID or some other piece of arbitrary data, we can use Zod to make sure that you're sending the right stuff. Because if you break that contract, TypeScript will immediately let you know and be like, "Hey, this isn't actually a valid input. It needs to be this."
And that's where the DX I think is grabbing everybody, why everyone's kind of gravitating towards this. It's because it's... My old workflow used to be like, I'll set up an endpoint and then I would have to go look at that endpoint code and be like, "What does it take again? I don't remember," or I will just kind of guess and then go to the browser, see that my endpoint failed in my network tab and I'm like, "Okay, let me go look at the code," whereas with tRPC, I just get that feedback immediately on my client side. And the productivity kind of just soares from there, I feel like, in my opinion,

Sean:
And I've definitely been guilty of that kind of trial and error procedure for [inaudible 00:14:44] API endpoint, send the params like, "Oh okay, what did I spell wrong? Let me see where the error is and crumb that tools."

Chris Bautista:
Exactly, exactly. It feels coding like that... So I use [inaudible 00:14:57] at work and I'll use tRPC on personal projects. When I'm not in any of those two ecosystems, it just feels like such a chore to do anything because you're just constantly switching files, constantly, like you said, trial and error, and it's no way to live your life. People just want to build fast and make sure nothing's break breaking while you're doing it.

Sean:
Yeah, exactly. Seeing the errors show up in whatever editor you choose before you go and test me just really speeds up the development cycle and Zod I haven't heard of. I've used YEP, but so if they're similar, then YEP is definitely a really good experience.

Chris Bautista:
Yeah, very, very similar. If you're familiar with YEP, you could use Zod pretty quick. The docs are pretty good and it's a very similar kind of API`, so nothing crazy.

Sean:
And do both of those kind of boil down to TypeScript types? Is it just a more convenient wrapper around making types?

Chris Bautista:
So I know Zod treats... It's more TypeScript first. I haven't used YEP in a while, but from the last time I used it, YEP wouldn't throw type errors. And I think after that then... This could just be personal experience, but when I was using YEP, the TypeScript experience wasn't as pleasant as it was with Zod. And then after using Zod, everything kind of clicked. And I actually want to give a shout out here. There's Matt Pocock who's like a TypeScript wizard on the internet. He has a Zod course. So if anyone's isn't familiar with Zod, take his free course on his website, and it'll pretty much just give you a walkthrough on how to use Zod and how it works with script. It's awesome.

Sean:
Oh awesome. I'll just check that out after this. Nice. Have you used the, I think it's the React useQuery library outside of this? I think that was the first that I've heard of that one, but I've been hearing that it's a really robust request library.

Chris Bautista:
So I think it's important to note you don't have to use tRPC with React. It's framework agnostic. So we have a vanilla client that you can just use with anything, but the community has been making adapters for a bunch of different frameworks as well. However, if you're using a React or if you're in the React ecosystem, we do have a thin wrapper around React Query, which I think is called 10 Stack Query now. But yeah, if you haven't used React Query, it's like... I don't know. I feel like it's become the defacto way to just doing your data fetching and in your React, unless you're using GraphQL or some other tool already, React Query is, from what I've seen, just everyone's been using it because the benefits there, the cache handling it does for you, it makes just caching so easy and it gives you a bunch of loud tools to invalidate cache and stuff like that, whereas a lot of people spin their own ways to do things.
They'll have their own use fetch hook and then manage their own cache some certain way. React Query just take care of all that for you. You no longer have to write your own use effects and stuff like that, just go use this. And since you're familiar with GraphQL Codegen, it's kind of a similar experience when you have these use hooks kind of exported from you. So when you go into some component you're just like, "Oh, just use get this or whatever and then it just does it for you." So it feels very, very similar.

Sean:
Yeah, it's so nice when libraries kind of remove some cognitive burden that you'd otherwise have to roll your own caching for example, which is hard to get, so it's nice that the framework does that for you.

Chris Bautista:
Yeah, exactly. Caching's one of the hardest things in the space, so it's no better way than to have a battle tested library do this for you. So that's like... I know I'm not smarter than them, so I'd rather have them do it for me than me. Right. That's kind of like how I see the scenario.

Sean:
Do you want to talk at all about the developer experience of using these tools? Because in the video you have a pretty sweet seamless setup where you're kind of flipping back and forth between server client code definitions. I think you were using Vim, is that right?

Chris Bautista:
So yeah, the development experience as far as, yeah... And then my talk, I was kind of bouncing between the backend code and the front end code pretty seamlessly. Again, you can do this in VS code or any other editor. You're just leveraging the language server or the types of language server. So Alex did this really cool thing, and I can't speak to the technical details of his technical prowess, but he was able to build a new version of tRPC in a way where you can literally just, if you're on a Mac command-click on some piece of your code and will literally send you to definition, and that definition would be living in your backend code. How that all works, completely magic to me. It's insane, but that's kind of unheard of. Typically, when people are working with their backend, they have to go find that file and go look for it or search all and then function name or something and go find that back end point.
Whereas with the new way of TrPC, you see with just using TypeScript, you just leverage TypeScript to literally enable us to just say, "Hey, click on this. It'll take you straight to your code or straight to the server implementation," and if you rename the server implementation or you rename the function, it will go and fix that on the front end. And it's great because we're literally just using TypeScript to power all this. We're not doing anything crazy. We're not leveraging any other libraries. It's just simply TypeScript enabling us to do all this stuff, which in my opinion is really great because I've become a really big TypeScript fanboy in the past year, going pretty deep into it. So it's amazing. You can kind of pull this stuff off and it just blows my mind this kind of stuff exists.

Sean:
Yeah, no, that's awesome. I always feel when I'm doing CTRL find all and looking through that pain and VS code that I'm doing something wrong or there should be a more efficient way, and it's nice that that is kind of made seamless with the tRPC.

Chris Bautista:
Yeah, exactly. When you rename something, the tooling does it for you. You don't have to search all and search all and replace, not like the stone age of web development.

Sean:
And so using this in Next, how does the server side rendering play into it?

Chris Bautista:
Interesting, interesting. Yeah, so in my talk, I kind of briefly went over it. Essentially there was a flag called SSR True that exists in the configuration. By default it's false, but if you want service site rendering, you obviously can just set that as true. The internals of how that work is a little tricky but effectively what it does, I think we leverage something from Urkel or from Formidable Labs. There's this pre-pass library that we have, which effectively just crawls your DOM and just looks for these calls. And as it goes through your DOM tree, it finds like a call, like, "Okay cool, let me execute this call. Okay, are there any more calls? Let's keep crawling your DOM structure. Is there any more calls? Oh, I found one. Let me go ahead and suspend and make that request as well," and so forth and so on. So that's kind of how that works. It's basically just recursively going through your tree and executing any request you can find and then essentially creating that down for you and then surface I rendering it.

Sean:
Yeah. So if you had to just pick, I mean we've talked about a bunch of different awesome aspects of tRPC, but if you had to just pick one part about it that you love the most, what do you think you would choose?

Chris Bautista:
So for the V 10 version, I think my favorite thing is literally what we were just talking about with the developer experience around just being able to go to definition of your server implementation and then going right back to your client code. That right there, I've never had that experience before and that's why... There was a lot of things I could have demoed on my talk, but I really wanted to call that out because I feel like that experience, at least outside of tRPC, I haven't had. And I thought it was just mind blowing that it was just that simple. I mean, I'm sure developing it wasn't simple, but for us, people consuming it, it just feels like magic to be honest.

Sean:
Yeah. I'm really excited to check this out after this.

Chris Bautista:
You should totally try it.

Sean:
Yeah. Well we've really appreciated you coming on. For our listeners, go watch the video. I think it's on YouTube making typesafe APIs easy with tRPC, so thank you, trash. And where else can people find you online?

Chris Bautista:
Yeah, so I'm on Twitch. I think my username is Trash_Dev or you can find me on Twitter @trashh_dev, but the Trash has two Hs because I think someone already claimed that name and I don't think they're going to give it to me.

Sean:
Awesome.

Chris Bautista:
Yeah, dude, it's been an honor.

Sean:
Well, cool. Thanks for joining us.

Chris Bautista:
Yeah, man. It's been great. Thank you. Thank you.