This looks really cool! The client side code is very readable and easy to understand, more so than when using REST APIs, but I can barely grasp what's happening on the server side.
Do you think it fits the situation in which there are multiple teams for frontend and backend and they are following a multi repo approach. I may be wrong but it looks more like a monolithic approach.
Hey, @sourabhkumar9876 ! Honestly, I don't have a lot of experience with mono repo tools, but I think tRPC would do good there since code is so easily shared. If you are thinking about multi repos - meaning some sort of micro services architecture, things could be a bit more tedious. I think it depends a lot on the architecture you are going with, but I expect you'd need to come up with some "tricks" to have your client code work with multiple trpc server instances. Definitely a topic worth looking into in more detail.
It looks like it'll only work on monorepos where server and client are updated and deployed together. I am not sure if this will work as seamlessly across multiple repos. If I have 1 server and 5 clients all in different repo I'll need to update everything. The only real benefit here is the type definition being generated 'automatically' on server side, as compared to using openAPI spec or manually defining them. Still an improvement for sure
@Tee Leo I suppose we're looking at two different aspects here. 1. Different communication technologies (RPC Vs graphql) and 2. Ease of development (how easy it is to share definition/generated SDK/code between projects). I'll skip 1 since I think we can probably agree they are rather different. As for 2, will using graphql libraries increase the ease of development in non-monorepo? As far as I know you'll still need to generate client stub/code from protobuf so it's not that different from openAPI or even trpc in this case. Or are you commenting on a different point altogether?
@Tee Leo docs/faq#is-a-monorepo-mandatory. Can't seem to post link here so I removed trpc's domain. It seems that monorepo is not mandatory but not using it practically brings us back to step 1 with the disadvantages in the first place. You're still right that it's designed to work with monorepo, just that it's not a hard constraint so thanks for pointing that out!
a simpler way would say to not keep the client and server in the same repo, its to make the export of the types remote, like having an addon where it linked to the servers and it automatically shows the available routes you are allowed in client without needing to have the server in the same repo
You said tRPC has no dependencies, but it uses Zod (and I believe React/Tanstack Query)... Do you just mean you don't have to separately install things?
only thing for me holding back on using tRPC is i couldn't integrate it well with Flutter/mobile apps. There's not much support for it for on mobile apps.
I think it should work well with any hybrid mobile tech that relies on TS (things like react Native or Ionic for instance). The "issue" with flutter is Dart, and the lack of a tRPC client available for that environment. Sadly, I don't think we'll see a solution for this one any time soon.
maybe you'll be better suited with gRPC. gRPC exists longer than tRPC. the difference is the use of Protocol Buffers (like JSON, just binary). im sure, you're able to generate a client for Flutter.
Dart will always requires you to write proxy classes to adapt the json format for exchanges. You can go raw but yeah it against the benefit of the type safety being promoted here.
@sirajmussafirr147 Honestly I'm still on the fence regarding this RPC as an alternative to REST solution. tRPC makes sense because I can write isomorphic code and have my entire codebase written in TypeScript. Once we need to add a different language to the stack, I'm still more comfortable using established, standardised protocols such as REST or AMQP.
Quick tip: Use fnm instead of nvm. nvm on linux is really slow and breaks sometimes. nvm on windows is a completely different project and it's fine. But fnm is just an overall better solution, been using it for years now.
Yep. As a downside though, Svelte Kit has the same issue as all other file system based router frameworks - a document tree that can easily get out of hand. For such scenarios tRPC brings way more value than the typesafety.
The only thing i hate is this feel like getting back on the 2010s where frontend and backend become on the same project. I reeally hate the idea of monolithic app.
We are definitely go in cycles. This is happening in all ecosystems though.. For a long time the monolith backend was the main option in the Java + Spring world Then, all of a sudden, micro services were the new trend, and everybody was writing micro services, even for the most basic apps... Then, a couple of years back I'm starting to see articles saying that monoliths are actually good, and they are the new trend 😒 So I just stopped worrying about this stuf, and I'm focusing on gaining an understanding on various tools, so I can decide what's the best approach for specific projects. I'm also valuing more speed of development and maintainability more than scalability these days, but, at the end of the day it doesn't really matter since software has this habit of being rewritten form time to time - www.quora.com/Is-it-true-that-Google-re-writes-Gmail-or-other-products-every-3-years-to-get-rid-of-legacy-code
@@awesome-coding yes it is indeed also depends on the project scale. but still, even without micro service, separating backend and frontend app is still a good way. at least for me.
But this is good. Microservices are not the same as multirepo. Sadly we got confused the last 10 years. But monorepos with multi-deployment are much more comfortable than multirepo - multideployment apps.
![NoCap - Maliboo [Official Music Video]](http://i.ytimg.com/vi/FUV7E0QyniU/mqdefault.jpg)
Can't believe we went back to strong types, memory management and rpc. Software is amazing.
It all goes in circles :))
A couple of days I posted something related to this - ruclips.net/video/ntzuRtFZ8KM/видео.html
tRPC made me fullstack as a TS frontend dev. I love tRPC and Zod
Great stuff Mate🔥🔥. Always waiting for your uploads. They are great for checking out new technologies.
Much appreciated! Thank you for your support!
This looks really cool! The client side code is very readable and easy to understand, more so than when using REST APIs, but I can barely grasp what's happening on the server side.
Do you think it fits the situation in which there are multiple teams for frontend and backend and they are following a multi repo approach. I may be wrong but it looks more like a monolithic approach.
Hey, @sourabhkumar9876 !
Honestly, I don't have a lot of experience with mono repo tools, but I think tRPC would do good there since code is so easily shared.
If you are thinking about multi repos - meaning some sort of micro services architecture, things could be a bit more tedious. I think it depends a lot on the architecture you are going with, but I expect you'd need to come up with some "tricks" to have your client code work with multiple trpc server instances.
Definitely a topic worth looking into in more detail.
It looks like it'll only work on monorepos where server and client are updated and deployed together. I am not sure if this will work as seamlessly across multiple repos. If I have 1 server and 5 clients all in different repo I'll need to update everything. The only real benefit here is the type definition being generated 'automatically' on server side, as compared to using openAPI spec or manually defining them. Still an improvement for sure
@Tee Leo I suppose we're looking at two different aspects here. 1. Different communication technologies (RPC Vs graphql) and 2. Ease of development (how easy it is to share definition/generated SDK/code between projects).
I'll skip 1 since I think we can probably agree they are rather different.
As for 2, will using graphql libraries increase the ease of development in non-monorepo? As far as I know you'll still need to generate client stub/code from protobuf so it's not that different from openAPI or even trpc in this case.
Or are you commenting on a different point altogether?
@Tee Leo docs/faq#is-a-monorepo-mandatory. Can't seem to post link here so I removed trpc's domain. It seems that monorepo is not mandatory but not using it practically brings us back to step 1 with the disadvantages in the first place.
You're still right that it's designed to work with monorepo, just that it's not a hard constraint so thanks for pointing that out!
You can also use asdf to switch between different language version including node
Thank you!
Nice but... On the server side it looks like is Typescript only, which is not a limitation of rest/graphql/grpc, am I right?
Yeah that’s the main caveat. Although there have been discussions about this concern, it’s still early days
a simpler way would say to not keep the client and server in the same repo, its to make the export of the types remote, like having an addon where it linked to the servers and it automatically shows the available routes you are allowed in client without needing to have the server in the same repo
You said tRPC has no dependencies, but it uses Zod (and I believe React/Tanstack Query)... Do you just mean you don't have to separately install things?
Do you really need tRPC in Next.js 13? Most of your data fetching will happen on the server side anyway.
This is a legit question. The main benefit I'm seeing in most scenarios is trimming down the file system if you are really leveraging API routes.
Next 13 is an unescapable curse, Trpc is supposed to be agnostic
only thing for me holding back on using tRPC is i couldn't integrate it well with Flutter/mobile apps.
There's not much support for it for on mobile apps.
I think it should work well with any hybrid mobile tech that relies on TS (things like react Native or Ionic for instance).
The "issue" with flutter is Dart, and the lack of a tRPC client available for that environment. Sadly, I don't think we'll see a solution for this one any time soon.
maybe you'll be better suited with gRPC. gRPC exists longer than tRPC. the difference is the use of Protocol Buffers (like JSON, just binary). im sure, you're able to generate a client for Flutter.
Dart will always requires you to write proxy classes to adapt the json format for exchanges. You can go raw but yeah it against the benefit of the type safety being promoted here.
pnpm is more efficient on all criterias than npm and yarn and supports node versioning aswell!
Volta is also a nice alternative to nvm
Thank you for pointing it out! This could actually be a good idea for a future video. 👍
🔥
z is imported from which modules ?
ok ZOD got it now ;)
import { z } from "zod"; :D
Sorry for not making it more clear.
Thanks I already got it 😉
How about gRPC? 🤔
@sirajmussafirr147 Honestly I'm still on the fence regarding this RPC as an alternative to REST solution. tRPC makes sense because I can write isomorphic code and have my entire codebase written in TypeScript.
Once we need to add a different language to the stack, I'm still more comfortable using established, standardised protocols such as REST or AMQP.
Quick tip: Use fnm instead of nvm. nvm on linux is really slow and breaks sometimes. nvm on windows is a completely different project and it's fine. But fnm is just an overall better solution, been using it for years now.
Thank you! Will keep that in mind!
Svelte creates types for your server components
AUTOMATICALLY
Yep. As a downside though, Svelte Kit has the same issue as all other file system based router frameworks - a document tree that can easily get out of hand. For such scenarios tRPC brings way more value than the typesafety.
@@awesome-coding Oh. The old-school way is still open with SK. You can build a rest API on a single file, and eat your cake too
What is the name of this feature?
Consider also CORBA.
Thanks for the suggestion! I'm not familiar with it. Any major selling points compared to REST + AMQP?
@@awesome-coding Unfortunately, there are no selling points.
@@kamertonaudiophileplayer847 Haha 😂 I figured!
The only thing i hate is this feel like getting back on the 2010s where frontend and backend become on the same project. I reeally hate the idea of monolithic app.
We are definitely go in cycles. This is happening in all ecosystems though.. For a long time the monolith backend was the main option in the Java + Spring world Then, all of a sudden, micro services were the new trend, and everybody was writing micro services, even for the most basic apps... Then, a couple of years back I'm starting to see articles saying that monoliths are actually good, and they are the new trend 😒
So I just stopped worrying about this stuf, and I'm focusing on gaining an understanding on various tools, so I can decide what's the best approach for specific projects. I'm also valuing more speed of development and maintainability more than scalability these days, but, at the end of the day it doesn't really matter since software has this habit of being rewritten form time to time -
www.quora.com/Is-it-true-that-Google-re-writes-Gmail-or-other-products-every-3-years-to-get-rid-of-legacy-code
@@awesome-coding yes it is indeed also depends on the project scale. but still, even without micro service, separating backend and frontend app is still a good way. at least for me.
@@ZynthProductions I can't argue with that :) you are right - it definitely is really compelling to have the backend and the frontend decoupled.
@@awesome-coding it is, having to imagine going back to have an apps that have bloated folder structure an size is 🤢
But this is good. Microservices are not the same as multirepo. Sadly we got confused the last 10 years. But monorepos with multi-deployment are much more comfortable than multirepo - multideployment apps.
Are you the former codeworkr? :)
I'm not sure what that is 😅
use trpc for new projects, not existing projects (period)
Html first… RoR ftw.
The OG!
@@awesome-coding yes sir.