Don't Migrate To tRPC

I love tRPC. I don't think you should go rewrite everything to try it. ❤️

#t3stack #fullstack #webdevelopment

[moneymayhem]

Clickbait / manipulative content is destroying YouTube

[taylorswe]

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...

[plexq]

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 Youtube 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.

[MattChinander]

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.

[TomDoesTech]

Hey, you're the guy from the Destiny videos!

[froxx]

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

[LuNemec]

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.

[noamisaac]

What's ya'll's opinion on the usage of tRPC in a non-monorepo context (i.e. via publishing a private package)?

[PyroFire-Firework_is_a_passion]

Spot on! Watched this at 9 AM, coded non-stop until 3:15 AM, and now my project's transformed from REST to tRPC.

[MikeHTMLAllTheThings]

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.

[kazuma]

No fkn way dude, my man changed his whole personality

[lewistyler]

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!

[penry]

One ergonomic benefit of tRPC that I've not seen many people praise is the component level SSR data fetching story.

[soulninjadev]

i literally decided to learn trpc today 💀💀

[anshnanda]

I migrated my whole app to tRPC in 3 days. Worth it! Was super annoying but new endpoints are much better.

[igetpaidtocode]

I use both trpc and normal queries due to an app we use, it's at least 5 times better when I want to implement something from tRPC comparing with vanilla node queries

[joshc]

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?

[joshuaborseth]

The t3 stack has spoiled me and now I don’t wanna work with anything else haha

[misterhtmlcss]

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.

[officialstrike]

First time I’ve been early to a video!