This probably goes without saying, but I'd thought I'd mention it. Doing a major overhaul to a codebase could introduce a lot of question marks about your app's stability. So, when I'm creating a new feature, I'll also refactor an old one, then kick it out to prod and watch them carefully. Slow and steady, rinse and repeat...
This is very true. Incremental refactoring also has the benefit that you're more likely to think about choices that you and your team makes, such as what kind of abstractions you need, what kind of performance to aim for, based on real stats and how important these features are to your product and users, compared to the time and effort you put into it. Major rewrites works very rarely (if at all) and often results in crunch, creating new and unknown problems that makes you to stay up all weekend. Not good for your mental health and work-life balanace, and not good for the business, because it most often that not does not result in more revenue.
@@dealloc Refactoring and rewriting aren't always the same thing. Incremental rewrites also have their own issues. You might require a bunch of "interop" code to make old and new code work together and that adds its own problems, mental overhead and potential constrains. I do agree that rewriting for the sake of rewriting just because you love some other technology more is usually a bad move on a larger codebase. On a smaller project with minimal impact it's very doable just because the amount of features and code is just smaller. What Theo has shown here it looks like he had something like 20 API endpoints and that's really not a lot. That's easy to migrate, especially since it's just Typescript code before and after and it's all logic code because it's backend (no UI code). It would be a different story if it was about migrating from Go/Python/C# to Typescript. Migrating UI code (frontend) on the other hand is a whole different topic as far as I'm concerned.
@@rand0mtv660 I agree with a lot you said here. Where I disagree is assuming that 20 API endpoints isn't a lot. Endpoints are abstractions and they most often than not, hide a lot of complexity underneath; middleware such as authorization, telemetry and analytics as well as integration with other systems which may not be trivial to easily rewrite for, even at the API level. And as we agree that rewriting just for the sake of it is a bad move, then you would just spend time on moving from one tech to another without improving the initial problems with the existing tech.
If switching from REST to tRPC is a "major overhaul" then it's architectured wrong. REST/tRCP/GraphQL are an adapter layer, they *should be* totally swappable. It's actually trivial to migrate when you encapsulate business domain in Use Case driven development without polluting it with any framework/infrastructure stuff. That aside, its trivial to make these work side to side with regular REST first and create new /trpc endpoint) rather than break it all for the clients. Again, make sure that your business logic is properly independent of frameworks and infrastructure stuff and that'll be easy.
I'm a pretty old-school guy, most of my back-ends are written in Scala/Play framework and front-ends in React/Typescript. I love how Honest Scala keeps you if you do it right, and how solid the solution you build tend to be - borderline bullet-proof. I have to say, as the Typescript stack has matured, I'm seriously considering if I should be taking more of a deep dive into tRPC based solutions (where it makes sense). I think for me, Typescript is the new hotness that Scala wishes it could be to a large degree. And this TH-cam channel has already clued me into plenty of libraries that really help connect the dots in a great way. So thanks for that - I recommend this channel to everyone I work with who cares about React/Typescript stuff.
I think Typescript would be more enjoyable for me if I had never used Scala. The combo of algebraic types and string literals as types in TS makes it possible to do pattern matching and gives great type inference on union types. That being said, after using Scala on a project I now find tagging every union type in TS to be tedious. But I totally agree with you, I think the modern TS stack is incredibly developer friendly and makes programming very enjoyable (Zod alone has changed the way I handle type safety across the whole application). But when I'm having to bring in Immutable.js as a dep or manually tag union types I do feel myself missing Scala.
I've migrated my large REST API over to tRPC because of the end-to-end type safety, client code generation, and better developer experience. However, I still have kept some traditional REST endpoints around for non-JSON data purposes, such as file uploads and XML responses (RSS feed). tRPC doesn't solve every problem but it solves 99% of them and I absolutely love it. Doing the migration, however, I kept a lot of RESTful API design implementation around so that my frontends can keep working as-is (just swapping in trpc/client) with the same data model and structure. My next step is to rethink the "endpoint" (function) designs to better align with this new world and not be coupled to RESTful standards.
When migrating to trpc, doing it step by step is a good idea. Especially in regards of stability. But when you start using trpc, like it, and keep on using it for new features, keeping the old graphql, rest, etc api in the long term is not a good idea imo since you have different approaches to request / send data for different endpoints. I'd prefer having a unique way for that in the long term
While the trpc may be super great dev experience, you are basically locking yourself to typescript only for backend and frontend. Thus making any future migration to different backend technology very costly. Since you cant just reimplement one backend endpoint at a time using different tech.
@@s4chinraja I think he means because of the programming language. You can write graphql apis and rest apis in other languages like Go, C, Python etc. But, it would still take a while... I think.
@@s4chinraja tRPC is typescript only if I get it right? That means you'll have to 1st rewrite the BE endpoint, then rewrite FE to use different tech, and then switch over. Compared to using protocol that is lanuage-agnostic, where you would just switch FE to new implementation using same protocol.
@@LuNemec Using tRPC most often comes with the decision to also use react query. So even if BE endpoint is rewritten in another technology, as far as the new endpoints can be consumed by react query (which will most probably be), your FE won't change much.
@@hyunchae1093 Yes, so it is plain JSON as usual. But then you basically loose any advantage of using tRPC - like type safety. Might as well use gRPC to have schema type safety, cross-language compatibility and a little efficiency bonus.
Honestly great advice. I'm just starting to use TRPc and it was a bit of a ramp up initially, if I had gone in trying to migrate everything it might have become a blocker. I'm now using it though and can't see going back to REST anytime soon.
I like what I see from tRPC but I'm currently not using a monorepo. The code reusablitiy from the monorepo also looks attractive to me. What are your thoughts on moving from distributed repos (some for multiple different front ends and microservices backends) to a monorepo?
I think the question that's getting dodged is whether or not tRPC will become obsolete if RSC / Next 13 becomes the meta for full stack app development. I have played around with the t3 stack and I love the ergonomics of tRPC, but I also love the ergonomics of Remix and the Next 13 app directory. What is the optimal path for full stack apps and DX? Am looking forward to seeing how things shake out!
@t3dotgg can you tell me that if I have a standalone next js application why do I need trpc, i'm asking this because the real benefit of using trpc is that you can have better client-server communication but with using getServersideProp and other similar function we can do the same. And the trpc endpoint can't be treated as rest endpoints. So lets say in your ping app what is the significance of using it instead of something like getServersideProp ?
but if it lets me migrate off of useSWR I should definitely migrate the one Page that's done before starting the next one I just started writing the SSG for, right? :)
Not sure about other languages or frameworks, but no one I've talked to that uses Ruby on Rails would feel this way. tRPC is much harder to use than Rails. Here are lots of reasons why; be aware the scale or my perspective is very large projects not Google size, but Medium Enterprise CRM size. Ok here is why: 1. tRPC's nested routing and routing in general. The structure isn't noisy and hard to discern. This is an area that needs to be memorized-ish on any project since the names are not always so obvious. It's just delay and cognitive load. I spend zero time in Rails on this problem. People will say "Roger, but you have a single file with all the routes and it's noisey". That's true, but due to conventions I open and file and can immediately without thought find what I need anywhere in the file and that's on bad projects done by weak devs. 2. Testing! Postman nor any other tool like that makes little to no sense, since setting up any routes is massively time consuming and wlll often run afoul of some procedure. It's hard graft just to do something that any RESTful API can do in 5-10 seconds. In development cognitive load is a huge cost on development. 3. Bug fixing: So you are clicking a button and you don't see a route or anything. No console log? Oh well. You are lucky if the developer created any kind of URL that will even hint at where that call is being responded to within your procedures and where it is based on a button click. This is one of the worst aspects of tRPC. I'm tired of griping, so I'll stop, but honestly if you are a nodeland user and haven't tried anything outside that ecosystem, then learn Rails and you'll see what I see. Also I really don't know why people think Typesafe code is such a huge thing; Github and many other large critical applications are written in Ruby which isn't typesafe. Typesafe is a nice to have, but good tests, that are easy to write and easy to reason about are more valuable.
In my company usually types are generated based on swagger schema for rest api and on graphql schema for graphql. I'm leaving comment for starting discussion. I'm really curious is that good way, or there is better solution.
@@kubagrott Yeah we do that as well where I work, but that's because our endpoints are .NET, so C#. Not really a way to import those directly into Typescript without a codegen step. We use "swagger-typescript-api" npm module to generate all types and an HTTP client class from Swagger/OpenAPI schema. Works really really well I gotta say. You just run a single command and get everything. This improved our developer experience 10x while working with endpoints that our backend developers create. This approach allows backend devs to use C# which they really like and us frontend devs continue using whatever we love. Even if we didn't do it that way, Swagger/OpenAPI docs that get created are really useful as API documentation in general, not just for generating Typescript types.
Look through the basic examples on the trpc docs. It really is 2 files, you don't even have to worry about a web framework (no express no nothing) just a client and a server (the built in one that comes with trpc for dev testing). Reading through the trpc docs feels like a tutorial. I'd start there.
That's what I thought. tRPC is useless if you are not using the same repo for both your FE and BE and if you are not using Typescript. Add It forces you to use React-Query. WTF!
2:27 - finally, the "slower" form of content pays off - Theo of yesteryear wouldn't even mention the possibility that there are shops that have their BE teams using other languages (also, love you mention Go / Python but not mentioning the most widely used language in enterprise / public sector land). Nonetheless, great video. Please more type of "slower" content, no need to go ballistic on every topic. Aspire to be Jack, not Prime.
Experience as time goes by and trying out stuff. That's really it. Just watching videos or reading blogs posts, but not actually trying out stuff will only get you part of the way there. Experimenting and forming your own opinion will allow you to improve more.
Clickbait / manipulative content is destroying TH-cam
its so annoying it makes these people all useless to listen to...blocking this channel from now on.
Even if i have subscribed to this channel, we should DISLIKE those video to discourage such cheap strategy !
He really said do not migrate your existing projects to tRPC otherwise he encouraged us to use tRPC in our future new projects
It isn't clickbait. *Migrating* to tRPC and *creating* a project in tRPC is different. Perhaps you were thinking of the latter one.
This probably goes without saying, but I'd thought I'd mention it. Doing a major overhaul to a codebase could introduce a lot of question marks about your app's stability. So, when I'm creating a new feature, I'll also refactor an old one, then kick it out to prod and watch them carefully. Slow and steady, rinse and repeat...
This is very true. Incremental refactoring also has the benefit that you're more likely to think about choices that you and your team makes, such as what kind of abstractions you need, what kind of performance to aim for, based on real stats and how important these features are to your product and users, compared to the time and effort you put into it.
Major rewrites works very rarely (if at all) and often results in crunch, creating new and unknown problems that makes you to stay up all weekend. Not good for your mental health and work-life balanace, and not good for the business, because it most often that not does not result in more revenue.
@@dealloc Refactoring and rewriting aren't always the same thing. Incremental rewrites also have their own issues. You might require a bunch of "interop" code to make old and new code work together and that adds its own problems, mental overhead and potential constrains.
I do agree that rewriting for the sake of rewriting just because you love some other technology more is usually a bad move on a larger codebase. On a smaller project with minimal impact it's very doable just because the amount of features and code is just smaller.
What Theo has shown here it looks like he had something like 20 API endpoints and that's really not a lot. That's easy to migrate, especially since it's just Typescript code before and after and it's all logic code because it's backend (no UI code). It would be a different story if it was about migrating from Go/Python/C# to Typescript.
Migrating UI code (frontend) on the other hand is a whole different topic as far as I'm concerned.
@@rand0mtv660 I agree with a lot you said here.
Where I disagree is assuming that 20 API endpoints isn't a lot. Endpoints are abstractions and they most often than not, hide a lot of complexity underneath; middleware such as authorization, telemetry and analytics as well as integration with other systems which may not be trivial to easily rewrite for, even at the API level. And as we agree that rewriting just for the sake of it is a bad move, then you would just spend time on moving from one tech to another without improving the initial problems with the existing tech.
If switching from REST to tRPC is a "major overhaul" then it's architectured wrong. REST/tRCP/GraphQL are an adapter layer, they *should be* totally swappable. It's actually trivial to migrate when you encapsulate business domain in Use Case driven development without polluting it with any framework/infrastructure stuff.
That aside, its trivial to make these work side to side with regular REST first and create new /trpc endpoint) rather than break it all for the clients. Again, make sure that your business logic is properly independent of frameworks and infrastructure stuff and that'll be easy.
That’s iterative refactoring, one of the key takeaways of the refactoring book by Martin Fowler
I'm a pretty old-school guy, most of my back-ends are written in Scala/Play framework and front-ends in React/Typescript. I love how Honest Scala keeps you if you do it right, and how solid the solution you build tend to be - borderline bullet-proof. I have to say, as the Typescript stack has matured, I'm seriously considering if I should be taking more of a deep dive into tRPC based solutions (where it makes sense). I think for me, Typescript is the new hotness that Scala wishes it could be to a large degree. And this TH-cam channel has already clued me into plenty of libraries that really help connect the dots in a great way. So thanks for that - I recommend this channel to everyone I work with who cares about React/Typescript stuff.
I think Typescript would be more enjoyable for me if I had never used Scala. The combo of algebraic types and string literals as types in TS makes it possible to do pattern matching and gives great type inference on union types. That being said, after using Scala on a project I now find tagging every union type in TS to be tedious. But I totally agree with you, I think the modern TS stack is incredibly developer friendly and makes programming very enjoyable (Zod alone has changed the way I handle type safety across the whole application). But when I'm having to bring in Immutable.js as a dep or manually tag union types I do feel myself missing Scala.
I've migrated my large REST API over to tRPC because of the end-to-end type safety, client code generation, and better developer experience. However, I still have kept some traditional REST endpoints around for non-JSON data purposes, such as file uploads and XML responses (RSS feed). tRPC doesn't solve every problem but it solves 99% of them and I absolutely love it.
Doing the migration, however, I kept a lot of RESTful API design implementation around so that my frontends can keep working as-is (just swapping in trpc/client) with the same data model and structure. My next step is to rethink the "endpoint" (function) designs to better align with this new world and not be coupled to RESTful standards.
Spot on! Watched this at 9 AM, coded non-stop until 3:15 AM, and now my project's transformed from REST to tRPC.
What's ya'll's opinion on the usage of tRPC in a non-monorepo context (i.e. via publishing a private package)?
When migrating to trpc, doing it step by step is a good idea. Especially in regards of stability. But when you start using trpc, like it, and keep on using it for new features, keeping the old graphql, rest, etc api in the long term is not a good idea imo since you have different approaches to request / send data for different endpoints. I'd prefer having a unique way for that in the long term
Hey, you're the guy from the Destiny videos!
tom do you know any way to use trpc in next js 13
While the trpc may be super great dev experience, you are basically locking yourself to typescript only for backend and frontend. Thus making any future migration to different backend technology very costly. Since you cant just reimplement one backend endpoint at a time using different tech.
What's preventing you from reimplementing one endpoint at a time? Also how is that different from other API tech like GraphQL?
@@s4chinraja I think he means because of the programming language. You can write graphql apis and rest apis in other languages like Go, C, Python etc.
But, it would still take a while... I think.
@@s4chinraja tRPC is typescript only if I get it right? That means you'll have to 1st rewrite the BE endpoint, then rewrite FE to use different tech, and then switch over. Compared to using protocol that is lanuage-agnostic, where you would just switch FE to new implementation using same protocol.
@@LuNemec Using tRPC most often comes with the decision to also use react query. So even if BE endpoint is rewritten in another technology, as far as the new endpoints can be consumed by react query (which will most probably be), your FE won't change much.
@@hyunchae1093 Yes, so it is plain JSON as usual. But then you basically loose any advantage of using tRPC - like type safety. Might as well use gRPC to have schema type safety, cross-language compatibility and a little efficiency bonus.
Honestly great advice.
I'm just starting to use TRPc and it was a bit of a ramp up initially, if I had gone in trying to migrate everything it might have become a blocker. I'm now using it though and can't see going back to REST anytime soon.
I like what I see from tRPC but I'm currently not using a monorepo. The code reusablitiy from the monorepo also looks attractive to me. What are your thoughts on moving from distributed repos (some for multiple different front ends and microservices backends) to a monorepo?
can you do a video explaining the server$() function in solid start compared to the functionality of tRPC?
One ergonomic benefit of tRPC that I've not seen many people praise is the component level SSR data fetching story.
I migrated my whole app to tRPC in 3 days. Worth it! Was super annoying but new endpoints are much better.
No fkn way dude, my man changed his whole personality
I think the question that's getting dodged is whether or not tRPC will become obsolete if RSC / Next 13 becomes the meta for full stack app development. I have played around with the t3 stack and I love the ergonomics of tRPC, but I also love the ergonomics of Remix and the Next 13 app directory. What is the optimal path for full stack apps and DX? Am looking forward to seeing how things shake out!
@t3dotgg can you tell me that if I have a standalone next js application why do I need trpc, i'm asking this because the real benefit of using trpc is that you can have better client-server communication but with using getServersideProp and other similar function we can do the same. And the trpc endpoint can't be treated as rest endpoints. So lets say in your ping app what is the significance of using it instead of something like getServersideProp ?
but if it lets me migrate off of useSWR I should definitely migrate the one Page that's done before starting the next one I just started writing the SSG for, right? :)
It is possible to hace the client tRPC on a React app running on a Kubernetes pod and the server tRPC on a BFF running on another pod?
Not sure about other languages or frameworks, but no one I've talked to that uses Ruby on Rails would feel this way. tRPC is much harder to use than Rails. Here are lots of reasons why; be aware the scale or my perspective is very large projects not Google size, but Medium Enterprise CRM size.
Ok here is why:
1. tRPC's nested routing and routing in general. The structure isn't noisy and hard to discern. This is an area that needs to be memorized-ish on any project since the names are not always so obvious. It's just delay and cognitive load. I spend zero time in Rails on this problem. People will say "Roger, but you have a single file with all the routes and it's noisey". That's true, but due to conventions I open and file and can immediately without thought find what I need anywhere in the file and that's on bad projects done by weak devs.
2. Testing! Postman nor any other tool like that makes little to no sense, since setting up any routes is massively time consuming and wlll often run afoul of some procedure. It's hard graft just to do something that any RESTful API can do in 5-10 seconds. In development cognitive load is a huge cost on development.
3. Bug fixing: So you are clicking a button and you don't see a route or anything. No console log? Oh well. You are lucky if the developer created any kind of URL that will even hint at where that call is being responded to within your procedures and where it is based on a button click. This is one of the worst aspects of tRPC.
I'm tired of griping, so I'll stop, but honestly if you are a nodeland user and haven't tried anything outside that ecosystem, then learn Rails and you'll see what I see.
Also I really don't know why people think Typesafe code is such a huge thing; Github and many other large critical applications are written in Ruby which isn't typesafe. Typesafe is a nice to have, but good tests, that are easy to write and easy to reason about are more valuable.
How did you approach real-time chat in trpc?
Websockets or polling?
What's the way to add rest to it? Like integrating an existing API.
Hey guys you think it's a jump of concepts learn trpc befor learning graphQL?
The t3 stack has spoiled me and now I don’t wanna work with anything else haha
Which cms I can use in t3 stack?
@dosomecoding
1 second ago
theo do you know any way to use trpc in next js 13
It works fine! Do you mean the /app directory?
/app directory is main problem. i want to migrate
@@dosomecoding we’ve got a long time til that’s viable because react context doesn’t work over server components 😅
i literally decided to learn trpc today 💀💀
you've missed the point. it's fine to use it.
Whats the best way to share types when you’re client and backend is not in the same repo?
In my company usually types are generated based on swagger schema for rest api and on graphql schema for graphql. I'm leaving comment for starting discussion. I'm really curious is that good way, or there is better solution.
@@kubagrott Yeah we do that as well where I work, but that's because our endpoints are .NET, so C#. Not really a way to import those directly into Typescript without a codegen step. We use "swagger-typescript-api" npm module to generate all types and an HTTP client class from Swagger/OpenAPI schema. Works really really well I gotta say. You just run a single command and get everything. This improved our developer experience 10x while working with endpoints that our backend developers create.
This approach allows backend devs to use C# which they really like and us frontend devs continue using whatever we love. Even if we didn't do it that way, Swagger/OpenAPI docs that get created are really useful as API documentation in general, not just for generating Typescript types.
"Chance's R..." is a great country western club. tRPC is great if you can make the rest of your org happy.
I've seen a few out there, but anybody have a good recommendation for a T3 or tRPC tutorial?
tRPC only. Jack Herrington is pretty solid choice for tutorials th-cam.com/video/Lam0cYOEst8/w-d-xo.html
Look through the basic examples on the trpc docs. It really is 2 files, you don't even have to worry about a web framework (no express no nothing) just a client and a server (the built in one that comes with trpc for dev testing). Reading through the trpc docs feels like a tutorial. I'd start there.
@@alastairtheduke it is possible to use tRPC front and back on separate Kubernetes pods?
@@paulomirandaarias9544 That I do not know as I have no experience with Kubernetes.
Can tRPC Endpoints be externally consumed (outside of the Next.js App) for e.g. a Python script?
yes. the endpoints structure is written in the document
TLDR: trpc is addictive, it has a very strong inhibitory response.
Another great video as always.
Guys, I am looking for a job that uses T3 stack.
Any recommendations on where to look?
Thanks in advance
Please make a video of how to implement trpc with the next 13 app folder 🙏
That's what I thought. tRPC is useless if you are not using the same repo for both your FE and BE and if you are not using Typescript. Add It forces you to use React-Query. WTF!
The only reason im using typescript is for frontend other than that i hate js/typescript
2:27 - finally, the "slower" form of content pays off - Theo of yesteryear wouldn't even mention the possibility that there are shops that have their BE teams using other languages (also, love you mention Go / Python but not mentioning the most widely used language in enterprise / public sector land). Nonetheless, great video.
Please more type of "slower" content, no need to go ballistic on every topic. Aspire to be Jack, not Prime.
Why don't we talk about module federation?
Your hair is amazing!
i write my backend in rust, so no trpc
Is this still relevant or can I ignore? Considering t3 stack is in love w trpc.
just do a full rewrite.
this is a cute bag but i would never wear this no i would not
You have amazing content, but why your video titles sound sarcastic :(
The content is good, the title is horrible.
love ur videos ,man u r just an inspiration to me ❤
Subbed to learn so thank you dude 😎
Theo 사랑해💚
First time I’ve been early to a video!
He's just talking nonsense :)
This is the way Theo! Sub 4 mins video with no BS, don't get me wrong I really appreciate your content but my time is precious and limited.
Idk why, but people saying time is precious on youtube commentaries always rub me on the wrong way,.
Is frontend and backend written in TS? Yes? use tRPC, else don't. Simple.
The guy doesn't have a point
I just subscribed
I love this video❤
Teach us how to understand this stuff so well.
Experience as time goes by and trying out stuff. That's really it. Just watching videos or reading blogs posts, but not actually trying out stuff will only get you part of the way there. Experimenting and forming your own opinion will allow you to improve more.
does trpc work with golang
not gonna lie, You are getting better at writing eye-catching titles. 😂
First🤫
Sorry son
I'm literally gunna u sub bc you always try to guilt trip us into subbing and liking lol. The good vids will get recommended to me by the alg anyways
Have you looked at gRPC? Support across many languages!
this dude changes like the tailwind