Alex: If you're using tRPC, you can sort of, as long as you using a monorepo architecture, then you can just infer your back end and any of your other apps, whether it's a mobile app or an internal admin app or your public website or whatnot.
Andrew: Hello, welcome to the dev tools, FM podcast. There's a podcast about developer tools and the people who make them. I'm Andrew in this, my cohost Justin.
Justin: Everyone, today we are joined by Alex Johansson. Alex is the creator of tRPC goes by Katt, K a T T lot online. So welcome Alex. So great to have you here. Would you like to take a moment to tell our guests a little bit about yourself?
Alex: Yeah, sure. I'm Alex, I'm a software engineer. I've been making websites since I was a kid, and professionally for 15 or so years. I've been bouncing around between front-end back-end and and mobile throughout my career worked a bit with everything.
[00:01:06] Getting into Code
Justin: Well, I was reading a little bit about your background and I saw that you used to have a business running Counter-Strike servers. I played a lot of Counter-Strike in high school, so I was like, oh, that's pretty sweet.
How'd you get into that?
Alex: well, um, that's sort of like how I got into like serious, like end-to-end everything from running a server to like a front end web programming. As a teenager, I also played a lot of Counterstrike server. So then when I was 13, we had a break in our house and I lost my gaming computer. And then most of my friends were sort of online and stuff, so I got more and more into like coding stuff.
Like I was still part of my team did a websites and whatever. And then eventually. I got approached by a friend of like an internet friend of mine from the same town that had a brother that had a server that he wasn't using in this company. And we had this idea of starting a Counter-Strike website where you could host your own server.
So it started as sort of like a form of where you sort of enter your details. You send me some money over the wire, and then it gradually developed to like a completely automated system where, you know, you go in, you configure your server, you buy it, it auto renews every month, if you can extend it, configure the server, do everything you want to!
Justin: That's awesome.
Alex: yeah, that's sort of, that's sort of the foundation of my web developer, what my whole like development skill is that company that I started at 16.
Andrew: That's super impressive. All I was coding at 16 was using a Wiziwig web editors to create one off joke sites. Didn't even think about starting a business.
Alex: I mean, it wasn't, I didn't really call it a business. Really. I made some money on it. Like as a teenager, it was good money, but like, it wasn't enough to live on.
Justin: Right. Yeah. I, you know, I, I hear a lot of stories about people who like, you know, as like I started programming when I was 14 and had this, you know, business doing this thing, I didn't, like, I tried to teach myself how to program and it was just Greek to me. And I was like, I don't understand a word of this.
It was like, it wasn't until college when I had like my first program class and I like, it just clicked and it's like, oh, oh, I get this. But before then, don't know... I... I... It was unfortunate that I didn't have like a comp sci program or something in high school. We just, we had, I did have a lot of electronic classes. I had actual electronics class and a robotics class, which ironically, to tie this all together in a robotics class where we did most of the time was play Counter-Strike.
Alex: Yeah, of course. Yeah. That's fun. I mean, everyone's way it's different. Right? I, I can't learn coding through, you know, getting taught by a teacher. I have to get my hands dirty. I only learn by doing, I think the old, I mean, I know the only programming book I have is the JavaScripts, the good parts by Douglas Crockford.
That's totally what I own and it's like this big.
Andrew: Yeah, I definitely agree with that. I don't think I've ever read a programming book. Uh, every new programmer I meet. I'm like, like the first thing I say is go build something like stop trying
Justin: Hmm.
Andrew: programming, just go build something you'll learn way more.
Alex: exactly. Why, why learn how a for loop works just like, yeah, it's pointless. Just like learn by doing. It's the only way for me at least.
[00:04:32] What is tRPC?
Justin: Cool. Well, maybe let's talk about, tRpc a little bit. Could you tell our listeners what tRPC is and what inspired you to create it
Alex: Yeah. Uh, so tRPC as a set of tools for making end to end type safe API. It sounds very wordy or complex when you say it like that. But essentially what it allows you to do is to write your backend and front-end in a more like integrated way. You basically write functions on the backend that you can then infer all of the types of f on the front end.
So you don't have to spend time writing a swagger schema or GraphQL schema. So it's an alternative to like rest or GraphQL for specifically for internal APIs. And it works for anything that is in TypeScript. So it did comprises type scripts on both sides to sort of get awesomeness of the type inference, but you can make like a react app or a react native app, and it's not actually tied to react itself so you can use it in other frameworks as well.
Andrew: And when you were creating it what were the alternatives at the time? W why did you choose to create something new instead of turning to what was already there?
Alex: So I, I, I was actually a contributor to blitz before I started working on tRPC and the problem, like I had some issues with blitz, but the main thing was that the only magic of blitz that I really wanted was this sort of like being able to import your code from the back into front-end, that's sort of like the only thing I cared about.
And then I stumbled on an early proof of concept of tRPC made by Colin... I forgot his last name, but he also created some other open source library, like Zod. And I just got super amazed that this sort of inference is possible from the back end to the front end and got completely obsessed with like building it.
So I took over the project in January and got like the first version in end of January or something like that. And then been, just been iterating on it ever since.
A big part of my inspiration is, like I mentioned earlier, I was born this sort of like PHP lamp stack. And, uh, back then you, you could write you're at a SQL or like a, your database call Next.js front-end code. So you just wrote HTML, then use called your database and you could use that data straight away.
And since moving to node JS 10 years ago, something I I've always missed the sort of productivity I had when I, when I could do that. And tRPC sort of like gives you that feeling that it's just like one big interconnected thing, of your front end and back end. And you can really move really fast.
Justin: Yeah, this is actually how I learned about tRPC. So for our. If you're not aware. Um, so blitz JS is an open-source project. That kind of seems like it's kind of trying to make a rails plus environment for the node ecosystem kind of.
Um, and, and one of their, one of their sort of Seminole features like Alex mentioned was this ability to have, uh, you sort of import your server code and use it in your client code and it just works? It like behind the scenes that sort of like, there's a, there's a build time system that comes through and like transforms that into an RPC call. And maybe in a second, it would be good for us to talk about like whatRPC is conceptually. Um, that might be important. But yeah, it's actually, when I did the same thing as I was looking through blitz and I was like, okay, I really love this.
I would like to see this and then stumbled across tRPC. So there's a, it's a cool connection.
Alex: Yeah. I mean, blitz blitz is powerful, but it's a really a wide product and you have to buy into a lot of different things when you choose to go forward to that stack. And if Brandon decides tomorrow not to continue to project your kind of doomed. tRPC sort of like is one part of the equation, but it's pretty easy to like migrate over from tRPC to GraphQL later.
If you want that to just copy out over the resolvers. There's no lock-in in anything else in your stack.
Andrew: So stepping back a little bit for our listeners who might not know what an RPC is, uh, what is that?
Alex: yeah. Yes. Yeah. So RPC stands for remote procedure call. So, I mean, it's bare in it's bare form. I guess it's just a way of calling functions in another system as if you're part of that system, but you sitting on the outside. So in the context of tRPC, it's like when you're in your front end, it kind of feels like you're in your backend, even though you're not.
And you can sort of use the backend function as if you're in that system, but you're actually just shimming an API call to the backend when you're calling functions. This might not be the best explanation of RPC. Maybe you can fill in some gaps in my explanation!
Justin: Yeah. I mean, I think that's good. I mean, RPC is, is, uh, conceptually like probably the old one of the oldest, if not the oldest, like mechanism of implementing APIs, it was like this, this idea that you have something that you want to call somewhere else. So, so RPC sort of evolved as like that mechanism. And this was like, to my knowledge, predated things like REST APIs and like that before those were sort of really formalized we had RPC calls.
there's a lot of systems that still use like XML RPC, which is like RPC over legacy XML protocol, which is kind of gnarly, but, you know, it's a cool sort of technology, but people often choose not to use that. I mean, we've had all these other API mechanisms that have evolved over the years.
Um, so. Maybe let's talk about like comparing and contrasting specifically in this case, tRPC with like some other technology. So, so tRPC gives you the ability or it's like, it's strongly typed on both sides because you're using TypeScript on both sides. So it's like you, you get this sort of like, close type inference between both your serving your client code.
But theoretically you could also get something like that via tooling around GraphQL. Why would you choose something like tRPC over GraphQL, or what are the trade-offs between the two?
Alex: Yeah, so I mean, GraphQL is amazing and I I've been a massive advocate and user for of GraphQL for five years. So I have a lot of love for GraphQL! One thing with what you just mentioned, you can achieve all of those things with GraphQL however, the tooling is kind of hairy. It's kinda a lot to learn. You have these code generations running to sort of create this type safe file on your front end.
You have to redeclare your schema several times. Cause you have a database schema, you have a GraphQL schema, then you have resolvers and then you have your front end that is using stuff. The main thing with with the difference between GraphQL and tRPC are not actually the main thing, but one of the things is like it's a lot more work to work with the GraphQL API.
It takes a lot longer to get up and running. The iteration cycler cycles are longer. However, once you have a GraphQL API, you can also like publicly expose that. tRPC is not trying to be a solution for sort of public APIs because by the nature, the only sort of guarantee of this schema's shape or whatever is in its type, which is just transient at the build time.
So there's no concept of API versioning, cause it's just like, ah, this is the data that function returns. And if you then deploy another function of data and if it's a public API, you'll get these like sudden breaks and whatever. The main thing is like it's a lot faster to work with tRPC than GraphQL. You can move a lot faster. With GraphQL and you get a little more safety in terms of, you know, you have field-based resolvers and stuff like that. You can do really granular authentication and authorization on that sort of like a pair of field level and a bunch of other stuff. But yeah, it's also like scaling GraphQL this real hard too.
Cause it's all post requests that are all looking in a unique way with tRPC, all the queries happens over gets, you can just put an HTTP cachecashier in front of your backend and happy days.
[00:13:28] tRPC Use Cases
Justin: So with a lot of these API strategies, it's like, oftentimes I think when you're trying to decide what should I use for product? Cause it's important to understand like how the API is optimally consumed. So for example, you, you said the constraint of tRPC is like, this is for a private API, you're communicating directly between some sort of backend system and your front end product.
Is it sort of like a one-to-one if you're like building a backend for front end, is that the sort of ideal use case or is it like internal product interfaces where it's like, you could have a mobile app and a web app both communicating to a sort of private backend system.
Alex: yeah. So you could have like five from 10 cent, one backend or bespoke sort of services for the backend architecture as well. And you conclude up together as sort of like one front-end experience. That's a big differentiator from the blitz as well. If you're doing a blitz API, you can only use it within that project. If you're using tRPC, you can sort of, as long as you using a monorepo architecture, then you can just infer your back end and any of your other apps, whether it's a mobile app or an internal admin app or your public website or whatnot.
Justin: Gotcha. Gotcha. Yeah. So it seems like, so tRPC sits firmly in that sort of like private domain. It's like, this is an internal API GraphQL sort of straddles that line. I actually. Um, I'm not a proponent of public graph, QL API APIs, because I think the, the sort of complexity of managing like DDOS attacks from like query complexity or like handling authorization, like there's a bunch, there's a whole slew of problems, caching all these things that make that actually really hard.
And then a rest end point, which is just, you know, HTP, it's like pretty easy to make that a public thing. So it's, it's, it's always interesting to know where it falls on the spectrum.
Alex: Yeah. I mean, GraphQL has a lot of those issues now, not, it's not issues. There's a lot of challenges that you have to become really good at. If you choose to adopt GraphQL. I've written some query complexity analysis on GraphQL, backends and stuff, and you're sort of guessing your way until you get the good benchmark.
It's just, there's a lot of hard problems. You sort of inherit when you choose GraphQL. That's that's not to say that it's bad. I think it's great. But yeah, especially when you're doing a public service, it's gets really hard to deal with those problems. When you have to think about all that attack vectors and stuff
Andrew: Yeah it seems like writing your API with tRPC seems a lot more natural than going into something like GraphQL where you have to learn this whole new language just to to write queries.
Another second order effect of that is if you're writing stuff like GraphQL, like my first GraphQL project, I thought I would just have types, but you don't just have types. You have to use all these tools to generate the types for you like, do you see a lot of benefits of the way tRPC does that? And you kind of like skip the code gen process.
Alex: Yeah. I, I think, I mean, that's a really, really nice feature with tRPC. You just have to install one package and then you just have all of that tooling automatically because it's part of the project. I've set up GraphQL tooling for type safety on, I dunno, 5, 10, 15 different projects, but it's hard every time and I'm not a junior developer.
So I can't, I think like most people deal with GraphQL. So they miss, the whole type safety aspect of it cause they end up used to writing a Java script front and that way, and not really using the great type safety that is in a GraphQL because it's too complex to fix all of that or like to hook it up.
So, yeah, that's a really good aspect of the tRPC is sort of like, you don't have to think about types type safety to a TypeScript that much it's just there. And if you just like write a function without any sort of TypeScript in it and return, it, it, it will work as if it is JavaScript and the sort of compiler we just tell you when you do things wrong.
So it makes it almost as easy as writing normal JavaScript or, but just with more like more help.
Andrew: Yeah. That's that's what a good TypeScript API should feel like. You shouldn't have to feel like, oh, I'm wrestling with TypeScript. TypeScript's the magic! TypeScript's is what makes it feel uh, the infer type I think you have in there, that's like, that's awesome. You just, you write an end point.
You infer it types are there. You're done. It's great, bit of DX you got there.
Alex: Yeah. Inferring types is so much nicer to work with than declaring types. A hundred percent agree on that!
Andrew: So you have, TypeScript does ,lots of enforcing of types at build time, tRPC provide a way those types at runtime. Since now you can. Kind of like, you know, the types of, lot more than if it were just types since we're using stuff like Zod and these other JavaScript, TypeScript checking libraries.
So does it do any runtime checking?
Alex: No, uh, it doesn't or, well, it does on input arguments. So anything you said from the client to the server has to go through a validator and that's validator can be Zod or Yup or joy, or this, a bunch of different ones I uh support. But that's one of the things I sort of like decided in architecture to enforce that you can't just say that the input is of this shape.
You have to say, this is a validator. And then I infer the types that that validator spits out on the other hand, however, on the outputs, I don't do any validation. You're sort of like, I trust that the server sends me what it inferred. And I don't do any further type checking than that on the runtime.
Andrew: That's cool. I really like how you designed it, where you can bring your own validation library and you didn't like create your own bespoke one.
Alex: I mean, there's so many good ones already, like, and I know how much work it's been for Colin. Uh, who, who wrote od, um, to just maintain that. Like it's not, it's not a trivial problem
Andrew: Oh,
Alex: a good validation library.
Andrew: yeah. I used IMTS to validate, uh, auto plugin types and it's, crazy what that stuff can do.
Alex: I've never gotten into IMTS. Uh, maybe you can talk a bit about IMTS
Andrew: Um, well, they all seem to have a pretty similar API. Uh, what I like about IOT S is that it's pretty close to what you do in type. So, if you want a partial, you use a ts.partial or whatever it is. it ends up being pretty easy. The validation part is like I wanted to have like rich error messages for bad types.
And I did have to write some custom validation logic for that, but it, it did work out in the end. It did take a little while to get my head wrapped around, like all the it.ts fp.ts. They
Alex: Yeah.
Andrew: Like, I don't obtuse APIs. Like, they're just kind of hard to wrap your head around if you haven't encountered that type of API before, but once you start to understand it, it gets, it gets a lot easier.
Alex: Yeah. I'm getting, I'm touching on the edge of functional programming and a lot of things I did. And nowadays, uh, but I haven't done the leap fully yet.
Andrew: Yeah. It's quite a big leap.
Alex: Yeah.
Justin: It is quite rewarding though. I think,
Alex: Yeah. It feels pure. Right.
Justin: yeah, it should, hopefully! doing it. Well,
I did have a question. It's a little bit of a change of subject, but a question about like transport layers. You mentioned earlier that the difference between tRPC and GraphQL, is that with tRPC you're doing a get request as opposed to a post request, meaning you can take
some advantages of, of caching, but in the case of GraphQL, nothing about GraphQL actually specifies that it must be done over HTTP. Uh, it's just like, that's the common implementation.
[00:21:59] Other tRPC Features
Justin: So just looking at tRPC docs. It looks like you're sort of like thinking about like transport layer a little bit under the hood. It's like, what might it look like if it was not a HTTP, Could you talk a little bit about?
Alex: Yeah. I've actually gone a step further down if you will. And that lower level RPC layer is like it's following JSON RPC and I've outlined a sort of spec on how, how that works. And then I actually support two transport layers. So I both support HTTP and web sockets. so you can actually do real time stuff with tRPC, as well as there's subscription support.
Then it looks sort of similar to how GraphQL does it. But yeah, the transport layer is not strictly HTTP. There is a lower level sort of spec on it and you can call this just like within the server as well. You don't have to go through HTTP layer.
Justin: Nice. Nice. And that uses a concept. It looks like that uses a concept called links. It reminds me a little bit of Apollo's links. You want to talk a little bit about that?
Alex: Links is a, it's a ways to customize how the data flow works from your client to your server. So for instance, if you have subscription support, you have a real-time app, you might want to have some of the real-time stuff always happening over web sockets, because it changes often, and you want to have like a push mechanism on that.
But then you might have some requests that you want heavily cached or whatever that you can customize that data flow with a link and say that if it's of type query, it should go over HTTP. And if it's off like mutation, then subscription, it should go over web sockets. So it's very heavily inspired from Apollo's links concept.
It's just like a way of saying like, okay, when, when the data flows goes to the server it should steer off in this way or that way, depending on your logic and you can add stuff like loggers and other stuff in there too.
Andrew: Super cool.
Justin: Yeah, that's awesome.
Andrew: Uh, So we've talked a lot about the things we find interesting and tRPC, but what are your favorite bits of DX that we might have not have discussed here? One that I saw while looking through the docs is the request batching seems pretty cool. Like you can either batch them yourself or just like do a bunch of requests and it looks like it kind of auto batches.
Uh, could you talk more about
that
Alex: So I was super excited about that's when I first released it. And now I just enabled it by default and sort of forgotten about it because it just happens now. But essentially if you have two quarries that happens at the same time, they will actually be put into the same HTTP request to the server.
And then the client has to do less work over the network. And the server also has to do less work because it only gets one HTTP request and you can create like the context object about that request once per request. And then it sends them all back as one big JSON body.
The main thing I'm excited about is I need to get this out to more react native developers, because I have not seen anything similar in terms of react native and the fact that we have like over the air updates and stuff nowadays makes it so fast to be able to write like your backend and your front end at the same time and just deploy it to the user straight away.
With over-the-air updates you don't really have to think about API versioning as strictly as before. And I think when people start realizing the . Sort of speed they can work with, if they use react native and something like tRPC, and not necessarily tRPC, there'll be a bit of a shift in that development too.
Cause who hasn't spent like countless hours on either complaining about swagger schemers, or writing uh swagger schemas. It's just like it's painful and no follows them because they're not actually enforced by the spec at least GraphQL is enforced in itself and self-documenting, but it's just wasted time.
Andrew: Does tRPC, you just mentioned self-documenting for GraphQL, does tRPC have a self-documenting feature? Can I generate a documentation website for my API or is that out of scoper?
Alex: Not right now. You can do it, you can generate it based on the input types, but you don't have any information about the output types automatically. I've been planning on doing features like that. I'm also planning about doing like an automated, a swagger schema and stuff based on tRPC.
Cause it was definitely possible. I just haven't spent that much time on it. I think that the way I like to write software myself is to have descriptive variable names over having too much documentation. So the way I would advise people when they're using tRPC would be a tab, like have bespoke input, variable names, that sort of self explain what they do.
But yeah, you can't actually document it unless you do some, some sort of custom logic.
Andrew: Does jsDoc work?
Alex: Oh, yeah, but that's to your actually do, if you have an output and you have, if you have a jsDoced object that you return your tRPC backend that will actually be inferred straight away to the client as well.
Andrew: Awesome
Alex: that, works
Andrew: I find JS doc to be some of the best documentation. Cause it's like, it's just so immediate. The feedback loop you hover, you click the arrow and you're like, oh, that's what it does. It's
Alex: yeah,
Andrew: my favorite way to read documentation nowadays!
Alex: Yeah. You can do that on the output, on the, on the input. You can't do that because it goes through a validater. In type script, you can't infer documentation in a generics unfortunately,. If you merge two types, you'll lose the documentation.
Justin: Mmm yeah, that's unfortunate. So you talked a little bit earlier about react native and wanting to share tRPC more with react native developers,
[00:28:16] Zart
Justin: you have this project template called Zart Z a R T, um, which is sort of a react native stack with tRPC. Would you like to talk a little bit about that?
Alex: Yeah. So that's just a starter project for sort of a react native. It's like a monolithic project where you have, if you clone it to start it, it automatically starts a Next.js app, a react native app though expo and a backend with tRPC and you can quickly, you can see that you get all the types in your react native app inferred are straight from your backend.
I want to do something more about doing a big push for that because I've really think this sort of development will be really beneficial for especially like smaller startups and stuff. Because it really enables people to jump back and forth between the front and the backend a lot easier.
Then however you choose to do things today. And the fact that you, as a font-end developer can sort of see what do you get back straight away and be able to just like jump over to the back end and change it and get something else I think will sort of bridge the gap between those two disciplines that are usually siloed in most companies.
And I find that super exciting because I think what most front-end developers will realize is that backend s a lot easier than they think in most of the cases.
Andrew: Yeah, lowering that barrier is a, is a theme we've seen on our recent episodes. We recently talked with Michael Jackson of remix and the way they kind of abstract away the API is, is very much the same. It, it brings it to the front end developer and it's just like, oh, it's not as hard as I thought it's just right there.
Same just another function in the file. So I think there's a lot of value in that
Alex: exactly. And, uh, yeah, I seem remix do a similar thing as Next.js does with the sort of like in line function um, that you can export, but they also have to post receivers, which is nice.
Andrew: So with project, have you used that type of architecture before? Have you built any apps where it's a monorepo of react native and react?
Alex: Yeah, I have, but not with tRPC in production yet, but I know a bunch of companies that are using that stack with tRPC and they're using react native and sort of inferring the backend with the help of tRPC and I've only gotten positive feedback from them so far.
Justin: And sort of mentioned this concept earlier, but there's this notion of this architectural notion of backend for the front end, which is like a slim backend system. That's, that's built dedicated for your product and it interfaces with other services. technologies like tRPC enable you to sort of stitch together that kind of system really trivially where you can have this like sort of facade to your other sort of business domain systems or system, whatever that looks like. And it's easier for your front end developers, product developers to sort of build like much more rapidly and sort of controlling their own API interfaces without having to have this larger API council or
whatever.
And like every product change is this big, you know, decision of like, oh, well, how do we, you know, how do we shape the API that doesn't break all of our products. If it's like expose a, uh, an easy interface to, to interact with your sort of like product services, and then just do a back end for front end and use something like tRPC then you, you get a lot of the sort of rapid approach to, to integrating with these systems.
So not having to worry too much about the sort of product to backend API interface.
API.
Alex: And the, and the amount of calls you have to do. Cause the backend it's not really made for whatever it can be like pagination with that little field that you need, then you can move that to this middle layer. Uh, is very similar to how I've the adopted GraphQL in the past in companies. I don't start by replacing all the servers.
It's you should start with is like, if you want to use this technology, this this type of API, you just like put it, put it in between first and then you can start replacing uh, services underneath without anything breaking for the consumers. mean, there's, there's a lot of talk about like, you know, GraphQL gateways and stuff.
Uh, it's really, good way of doing stuff, ideally like if you're a decisive company that needs that of likebackend for frontend I would probably advise those to just to build a GraphQL server for your domain. you start to know your products over using something like to tRPC.
Justin: Yep. Yep. Always good to know when you should use what tool or what they're good for.
Alex: Yeah. I'm trying to not to be too bullyish about everyone should use tRPC or whatever. I The community they get so fragmented when the people are just so sensationalist about whatever technology they've created or like, it's just like, there's always trade offs, whatever.
Um, mean, tRPC is experimental, not, not experimented in the way that it's unstable, but it's going to change and uh, people need to rewrite some of their backends when they do a new, a new major version, whatever. just things to be aware of Uh, do you pick technologies, right?
Justin: Yep. There's a constant tension between hubris and humility for toolmakers. So it's like, you
know, does my tool solve all the problems or should I just really step back and say it only does, you know, this one thing.
[00:34:07] To the Future and Beyond
Justin: What does the future of tRPC look like?
Alex: So the next thing I'm really excited about doing now, it's an idea of how last week, I'm gonna start doing a sort of kitchen sink for tRPC, a sort of think of it as a tailwind ug components or tailwind UI, tRPC. Where I'm just going to do a should showcase gallery for a lot of different design patterns and how you use tRPC at different ways with, uh, previewing, like the front end and the back end, but you can just copy, copy and paste code over to, to your app.
things I want to do is sort of like this REST adapter that I talked about earlier, that's definitely something I want to work with. There is some challenges when you build really, really large APIs. With tRPC right now that I have to work a bit on. uh, you get to something like hundred procedures in your backend, it starts getting a bit laggy-ish on the front-end because it has to infer the types of all of these, all of your backend and type inference is amazing.
And, you know, inferingtypes, over declaring types is so good for developers experience, but it is a slow at a certain scale. And so I need to do some systems for that.
Another nut I want to crack it's like, I want to be able to find some way of monetizing tRPC now that it's getting quite a bit of adoption, because obviously as any open source, maintainer will say is they spend so much time on it get no money.
And I'm, you know, taking time off doing consulting engagements to do tRPC. Consulting pays really well, tRPC pays up $200 a month right now. Um, which is
Andrew: yeah,
Yeah. Probably the, the one way I just some sort of hosted service. It seems like that's the
Alex: yeah,
Andrew: go-to for most of these.
Alex: yeah. Don't want to do that though.
Andrew: Ah,
Justin: Yeah. Or it could
be consulting with tRPC.
Alex: yeah, I do that. I do that. And that's really fun. I mean, I love those projects where I get to, you know, implement and use tRPC. And people, you know, implementing it, see happy it makes the other developers.
Justin: Yeah.
Andrew: Yeah, it's always awesome to see the fruits of your labor.
Justin: it's really hard to, to monetize open-source. There's an interesting, sort of another interesting parallel, what last week or so rich announced rich Harris announced that he'd be joining vercel, and, and this sort of spawn this whole thread about like the role of open source for companies like Vercel and it's poignant to this conversation because like, oftentimes the thing that open source is, it's like, yeah, you have this tool that's free that people can use.
But many times for businesses, it becomes like a marketing thing. It's like, you know, we, we, we give you this tool to say something about our brand and this sort of like build up some perception of like who we are, you know? So like
Next.js for Vercel is definitely like, it's more of a
marketing tool than it is anything else.
And, and I think there's a thread, there's a nugget of wisdom there to sort of pull on it's maybe like just learning to really lean into that, that like this open source project is sort of a marketing thing is, is a way to figure out monetization from a different angle. So, you know, again,
if it's like consulting, it's like a content creation or whatever, it's like, you know, I build this tool to, to generate interest, to, to
Alex: Okay.
Justin: this market anyway.
Alex: I started tRPC too you know scratch my own itch. I had a startup last year and I had my own VC funded startup. Uh, and I was missing this tooling that sort of like started doing it on the evenings weekends. Um, but I'm not, I'm not part of that company more so I can't use therapy to promote that or get that company to promote a tRPC.
But it's an interesting, the whole hiring of rich Harris. How the reasoning behind that was. I know svelte is, I mean svelte is felt this amazing, and I love for that to get more funding and Rich to get more time, but like the business angle of it I don't fully understand more than marketing.
Justin: I have many opinions about this and won't spend too much time on it, but I mean, Vercel is a hosting platform. I mean, that's, that's
fundamentally what they are. That's, that's their moneymaker. They are not in the react business.
So they support a lot of tools, but those tools make them no money. They are essentially marketing.
And, and the biggest thing that they want is they want to provide you the tools that give you the easiest inroad into their platform. And right now they've like done a really great job with Next.js in the react ecosystem, but having rich on board and to make that story easier for svelte means that two of three big players, or maybe two of the four big players, if you count angular are sort of in this, in this space now.
And if they can provide that sort of first-class story,
then you know, they start becoming the de facto of like the platform that you go to to
host your, your stuff. And I think that's the big, that's their big play.
Alex: Yeah. What do you think about the future of you know, are react versus svelte versus et cetera?
Justin: This plays into a good question that we were going to ask you. So I'll turn this around on you a second! I think, I think svelte it's a great technology. It was like
a very clever
innovation from Rich. And I think it will continue to grow and evolve in ways that like other platforms will struggle. React is very complex. But it, it does what it does very, very well and the team behind it. It's just, they're so incredibly brilliant. So as server components come out and like these more sort of robust interfaces come out for doing things like better server-side rendering, which react struggled with for a long time,
you know, I think that will just help ecosystem.
I don't, I mean, I, I just see all the things continuing to grow, uh, unless something major changes like Facebook gets broken up or their team or the react team sort of gets gutted in some way. That would be pretty devastating because react itself is, is an incredibly complex technology. Whereas I think svelte is, is more like approachable in a way, if you're wanting to contribute to one or the other.
This is no, you know, again, nothing against react. I think that like, that team is amazing and they have done their best to make it easy to contribute, and a lot of people do contribute to it, but, you know, trade-offs.
But to turn this around on you, so what do you think the future of the web looks like and what are you most excited about?
Alex: The future of the web. I mean, I definitely, I'm very biased on this, but I definitely feel like we're moving.... the shift is going back to mama lifts in general. Like we've had these broken up microservices as a trend the last 10 years. And I mean, I don't think that's a revolutionary opinion, but we are definitely moving back to the sort of integrated developer experiences.
And that excites me because it gives you a big productivity boost. And you have to spend less time on infra and stitching services and whatnot. But in terms of web development, what is the next big thing? I think I really believe in smelt as a technology, like everything I've seen about it, just feeling like it just makes sense. And if one of the things that is really hard with react is like, it's hard to do react well. There's a hundred million ways of doing react wrong and there's a few ways to do it right. And they're hard to get the right. And svelte seems to have found like a really good way of writing really performance web applications in a way that is very approachable and easy.
And you have less chance of fucking up your code. So I'm really excited about that.
Andrew: Yeah, I love react to, but algebraic effects of have set my mind in a flurry a few times.
Alex: yeah, on it's it's just hard and it is sort of like this sort of like array with dependencies that you have to have, and then sometimes you have to memorize like complex objects. Like ended up prop drilling is also hard, you know? And then if you don't want to do uh prop drilling you have to do like this context provider and then that's hard.
This is so many things that are by design, difficult in every act to get right. Not to say like a love react, I've used it for seven years. But I still struggled with it. And I feel like after seven years with the technology, I shouldn't struggle it with it. There should be like error or like,
Justin: One like baseline thing that I would say is when I think about the future of the web, I think compilers are the future of the web. svelte is part of that story.
You might even say DSLs, domain specific languages potentially, but, but definitely compilers being a central story in the web, you know, web assembly is a thing that's, that's, growing larger and larger, but pretty much all the tooling that we have now is enhanced by better and better compilers.
So now we're moving out of JavaScript to get even better sort of performance for our compilers. So, you know, there's Lee from the Next.js team, like put on an article about rust as the future of like web tooling or whatever.
Um, so I think this is all just a Testament that we're doing more and more complex compilation to sort of use the web as a target, less so than like we had to do all these weird things to like, you know, I guess hit the
Alex: Yeah.
Justin: like, we can use it as a target.
Alex: I think compilers are really interesting. Like I've been really careful with tRPCs not to do any sort of a compiler of it, but I might end up there eventually. And I'm super excited about WASM. I can't wait for the day where, you know, everything is in place in rust or whatever other languages language there is.
That gives me this like full experience. The TypeScript does. Like I love TypeScript and I will stick to that until I have something that can replace all of TypeScript, not just this compiles to a no. Okay. frontenda library or a hard really hard to write back end. Um, but I like to have like the same language everywhere until there's a really, really good reason not to.
Justin: Yeah, always bet on TypeScript.
Alex: Yeah, I've done a big bet on it. way
Okay
Andrew: With that.
I think it's a good time to transition into tool tips.
[00:45:28] Tooltips
Andrew: So my first tooltip isn't really a tool tip. It's talking about new features in TypeScript I think are a long time coming and really, really nice. First up is the awaited type I've wanted to do this so much. So many times I've turned to type Fest and like copy and pasting answers from stack over.
Finally there's a new type in TypeScript called awaited, which unwraps promises, even deeply nested promise which that's pretty cool.
So you can actually get the, the value that the promise will return. This makes it a lot easier to extract values from, from functions. Like recently, I just had a function that I returned to some JSON object and it was in a promise this type of type easy to extract that object interface from the return type. So super excited to see.
Another cool one whicha lot of people have complained about is when you upgrade TypeScript, you also bring along all of the library upgrades, and that has the potential to break your builds. So going from a minor version to a minor version of TypeScript can often result in a lot of things breaking because those underlying libraries have changed. Now those libraries are published to NPM and you can depend directly on them. So even though you're upgrading your version of TypeScript, your Dom types don't have to upgrade. So that's, I think that's huge boon to productivity, and then there's a bunch of other cool stuff. One I'm excited about is top level await. Cause every time I write scripts, I always have to create a main function in my JavaScript no more. Now you can just await away.
A few releases back, they added type imports, but the kind of shitty thing about them was that you had to create a second import statement where it was
Alex: yeah.
Andrew: only imports. Now you can just put that straight in the import statement it works.
Justin: Uh
Andrew: So that'll clean up a bunch of code. Cause I don't like seeing multiple lines importing from the same module. So that's, that's pretty cool.
Alex: yeah, but ES modules was planned to be in this release, but they pushed it for 4.6, which I'm sad about. Cause it's, I hope, I think it's blocking as me really releasing Vue support for tRPCs.
Andrew: Ah, yeah.
ES Modules slow moving beast.
Alex: Yeah. I spent a day battling with interoperability between common JS and ES modules a few weeks ago.
Justin: That's sort of our parallel to the Python two to Python, three thing that was like such a terrible thing in that ecosystem for us, it's like IES modules,
Alex: yeah,
Justin: Common JS, ugh!
Alex: There's some, some things you can't even use nowadays, like a note fetch.
Andrew: Yeah.
Alex: but maybe
Andrew: upgrading a dependency and then it's like, oh, they decided to ESM was now and now I have to add all this tooling and configuration just to deal with this one dependency or just stay on the old version
Justin: Yup. Yup. So my first tool tip of the day is a tool called T L draw. So this tool is from Steve Ruiz. So I've been following Steve on Twitter for a while. His Twitter feed is just an absolute delight because he shows these really short GIFs of him messing with like UX experiences, like tiny UX experiences, like, oh, what is it like to resize these group things?
Or like, how does these things supposed to behave when you move them around or whatever. It's such a joy to see him iterate on this. And, and so he's finally sort of released it. It's open source. There's a vs code extension
that you can use to have TL draw, like right in your browser. So you can, you can think of a TL draw kind of at like, Oh, boy, why did I just go blank?
What is the other Excalidraw? There you go. You can think of TL draw like escalidraw. It fills a very similar niche. It's like a very simplistic app just to sort of sketch some stuff in works great on mobile mobile web, like, so, you know, that's, that's nice. I've got multiplayer. It's, it's a really delightful experience.
And again, if you go through his Twitter feed and look at all the, just all the little iterations that he's done on just getting things to feel good. I mean so much great work. Steve is just excellent. This library is excellent. Definitely play with it. And if you really, really like it, you should definitely support him.
Again, same sort of thing. It's like we have a lot of people working on this really excellent free tooling. You like it support it. Same as tRPCyou like it please support it.
Alex: I didn't know what to put, but I'm sure .This has been up on the podcast like a couple of times already. Prisma really love it. Like, especially if you work with like tRPC or GraphQL or whatever typesafe stuff. Prisma is an ORM for mysql and Postgres and I think that Mongo DB support now, but it's not really a conventional ORM cause every query. you write you get back a pure object that you can't performing the operations on. So it's actually a query builder, but they call it an ORM cause it's easier. And to have a lot of good tooling for your like building your data modeling and automatically generate an SDK for your database, that's really good to use.
And with rTPC then you just return that object, that query, and you can use this straight on your front end. If you change your database migrations, you get type errors straight away on your, front-end all the way thougj,, so it's a really nice experience to work with Prisma.
Andrew: Yeah. My favorite thing about it is the hassle-free migrations because we
Alex: Yeah.
Andrew: have that in our code base and literally have to write an up and a down for, migrating and sometimes writing. Down is pre pretty intense and I am not the versed in sql
Alex: You can just skip that as well. Yeah. I've wrote a really complex Postgres migration the other day and like, yeah, you sort of there, the great thing about prisma is like, you kind of forget how to write the sql cause it just, you, you barely ever have to, you know, jump out of what they gave you from default, which I've never felt with another way ORM
Justin: Yeah, another big shout out to the prisma team. They have really, really good, like a really, really good language server for there. So they have their own schema language sort of where you sort of described the relationships of things. But so if you're like start a relationship, if you're like, Hey, you know, this, this type has, you know, many of this other type or whatever is you're describing like a one to many or many to many relationship it'll like automatically fill out everything and all the places that you need.
It's it's magical. It's so good.
Alex: Yeah, the editor experiences sick. I love it. And yeah, it's just it just works. Right. I've had very little issues with it
Andrew: my last tool tip for the day is next-auth. Auth is of the times a pain and a hassle to set up, but I've turned to this library countless times add authentication to my next JS applications. And it's just so easy. Right now I'm building an app called Pitchforkify, which takes all the Pitchfork album reviews and then connects it to Spotify.
So it's easy to listen through them. And they had a Spotify provider and I got my auth up and running in like 10 minutes compared to with it for hours and hours. So if you need an authentication solution, I'd highly suggest a Next.js auth. If you have an Next.js application.
Alex: Another guy that got hired by Vercel by the way.
Andrew: Yup.
Justin: Oh, interesting. Interesting. That makes sense That's a, that's
a clever one.
Andrew: Yeah. The easiest past paths to open source monetization. Just get hired by Vercel
Alex: yeah, exactly.
Justin: Well, I mean, so I, I do wonder, and, and, and I almost hope that more companies in the UK system kind of follow suit, because one of the best ways to fund people who do open
Andrew: It's just
Justin: source is tired of them,
Andrew: TypeScript
Justin: actually give them a job, you
know? So, you know, so long as that can become a non exploitive relationship and they can kind of continue to do their thing, you know, I'd love to see more of that
Andrew: Yeah,
Alex: A hundred percent.
Andrew: donating like $10,000 randomly.
Justin: because
at the end of the day, it's like,
Alex: to either.
Andrew: deeply That's pretty
Justin: know, when you're like, I have to live, pay rent, you
Andrew: promise
Alex: if it's monthly, that's good.
Andrew: Yeah. If it's
Justin: Yeah,
Andrew: that's great.
Justin: yeah, yeah.
Alex: I mean, there are some people making proper bank on open-source right. It is possible,
Justin: Yeah,
Andrew: makes it really
Justin: the, amount of people is very small,
you know, it's like,
Alex: them by name.
Justin: it, it it's somebody like Evan you who can like, you know,
Andrew: which
Justin: live on it. Whereas like, you know, most people can't,
they don't, they make
Alex: Yeah.
Justin: change. they don't they make
Alex: Yeah I don't know if I would want to either. Cause like I like build tools to, because I scratch an itch itch of something I want to use. So then I don't get to use the tool either.
Justin: Yep. All sort of depends, I guess.
Okay. My last tool tip of the day is this library that I ran across called co-share. So co-share is essentially an application that it really, really easy to do real time synchronization of a client. This is a hard problem. There's been a lot of libraries that have like, come out over the years to solve this and, you know, way back in the day there was like shared JS.
I don't know if any of y'all ever used that, but you know, there's been like a lot of research on CRDT's and, know, all these mechanisms to like make this kind of thing happen. It's really, really hard. This co-share library is nice because it gives like a relatively easy interface to just kind of slap this in front of your already preexisting app and make it work.
You know, again, all of these things, anytime you have a real-time system like this, there are always trade offs that you will hit, and unique constraints to that system set up. So this is not going to solve everything. They have some different implementations of networking interfaces. So like for example, they have a socket IO interface, which a lot of people were making like multiplayer games and the node ecosystem we'll use like socket IO.
So, you know, there's complexities to it still, but it, it's just a nice, a nice way to bring multiplayer to your app, bring real-time collaboration. So that's the thing that interests you definitely check.
Andrew: This package, they linked to simple-peer seems pretty interesting, too easy. Peer-to-peer
Alex: Very cool. I want to check out all of these.
Andrew: Cool. More tool tips, Alex.
Alex: I mean tRPC, maybe. I don't know if I mentioned it before on the podcast, check that out.
Andrew: Okay, well, that's it for this week's episode of dev tools, FM, thanks a lot, Alex, for coming on this we tend to talk about front end things, so it was nice to talk about back end things for a change.
Alex: Thank you. It's really fun being on.
Justin: Yeah, I really enjoyed it.
Alex: If anyone wants to like yeah. Shout out to anyone that wants to talk about tRPC. I love hopping on a call or Twitter, DMs or Twitter, public, whatever. Hate it, love it, at me.
Andrew: The online nature of everything.
Well, that's it for this week's episode of dev tools, FM, be sure to follow us on YouTube and wherever you consume your podcasts. Thanks for listening.