Is tRPC The End Of REST/GraphQL?
VloĆŸit
- Äas pĆidĂĄn 27. 07. 2024
- Thanks to Mailgun for sponsoring this video! Head to mailgun.com/webdev to try Mailgun today.
tRPC is an incredible library that makes working between your client and server so much nicer. The best part of tRPC is how it brings type safety to your API and client interactions which is something I have never seen done before (especially so well). In this video I talk about what tRPC is and why you should learn it.
đ Materials/References:
GitHub Code: github.com/WebDevSimplified/t...
What Is Zod Video: âą Zod Makes TypeScript E...
Zod Crash Course Video: âą Learn Zod In 30 Minutes
đ Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
â±ïž Timestamps:
00:00 - Introduction
00:56 - Sponsor
02:07 - What Is tRPC?
02:45 - REST Example
06:14 - tRPC Example
#tRPC #WDS #TypeScript
Thanks to Mailgun for sponsoring this video! Head to mailgun.com/webdev to try Mailgun today.
Everyone has probably noticed that a lot of modern practices are now mostly old patterns and principles being rediscovered and adapted to modern ecosystems: RPC, Server-side rendering, Functional Programming, having Types, modular monoliths...
Java RMI all over aggain xD
That's how people make money đ€Ł
This is why I still program in COBOL in 2024.
Yeah we've gone full circle, we're doing server side rendering again.
You can't compare this to REST or GQL. With both those, the expectation is that the server and client code are decoupled - like if you have an API and a UI. With tRPC, it only works if the client and server code are part of the same application. At least that's how I interpret it.
Graphql is very much more useful than trpc when client and server are two completely different apps (which is much more common)
Why?
You can have a shared package that has the trpc router type to use at multiple consumers.
There are monorepos coming for building web and mobile apps in one project
@@thekwoka4707 you're assuming both are TypeScript. They could be two completely different languages instead, like Rust and Flutter, which is what in using.
@@thekwoka4707 only in javascript land. people prefer golang over nodejs when when it comes to scale.
I like my types
I love your videos. Short enough, straight to the point, and very interesting and valuable for any JavaScript dev. Itâs also great that you add a gh repo in link so we can examine the code and play around. Please keep doing that. Good job man !
A mature tech like graphql or rest is never going to die they will always have their own space and will be used for years to come.
yep, even graphql didn't kill rest when naysayers that was gonna be the case when it came out.
this is only good if you are solely doing fullstack and have control of both fe and be.
@@metalsadman not true
This looks great for calls to the same server/network, but external services would require a shared object to make the type safety work. It would have been great to include the disclaimer of this limitation.
Exactly and than there is hardly a benefit when comparing it to well typed https calls e.g. with axios.
I was thinking to slowly shift to the t3 stack made by Theo and your are helping me do it faster by explaining each technology that stack uses!
Don't just shift something for the sake of an online influencer telling. Do your own self exploration, evaluate based on your use case and then decide. There is no single solution (stack) to all kinds of problems.
@@sujit_webdev Actually, I will just try it on a new project as it seems promising. I will not shift my current projects into t3 stack (which is not worth it at all), but I just want to try it out once as you can't comment on something without actually trying it
@@sahilaggarwal2004 Yes, I agree with you totally! đđ
u still using T3?
Hey this tRPC thing is pretty cool
Very straightforward and easy to understand. One of the best tutorials over tRPC. Looking forward to the full tRPC project!!!
Thank you for this REST/GraphQL comparison. Super helpful!
Thanks Kyle. I would be interested in a trpc tutorial. Between trpc and zod you are so safe you can .
Was waiting for this. Thanks
SvelteKit offers endpoint typing out of the box automatically!
Solid Start has $server functions which are like on demand created endpoints that can be written directly into where they are consumed, which is pretty dope.
Very useful video! Looking forward to viewing more
Need a full in dept tutorial on tRPC very similar to your ZOD tutorial(awesome tutorial). Please!
That's really cool. I imagine that if the Backend and Frontend are separate repositories, we can simply have some kind of automation to connect them because not all apps are in a monorepo. e.g. A Github action that takes the generated types from the BE and create a Pull Request in the FE project with the changes types
Not sure what you get out of this but separate repo for FE and BE can happen regardless if it's tRPC, REST, or GraphQL.
@@arvi8843 And how we import types from app router ?
@@Ilohimushka You install a special npm package thet contains BE types.
â@@ukaszzbrozek6470Is it automated? I'm confused how the workflow will be when changes are made on the backend?
tRPC is going to replace REST/GraphQL the same way MongoDB replaced SQL
Lol, I like the analogy
Funny that some of the older JS tooling already does this. Meteor with the zodern:relay package does this. And what's more, it works on realtime data subscriptions and supports piped operations and rate limiting.
You can easily type the return JSON from your APIs by using VS Code's "JSON to TS" extension. Just trying to spread the word.
I do like the type safety, but I can live with the types being generated in graphQL for now as GraphQL also allows us to not over fetch when serving data to different platforms like a mobile app vs website. The client can request only the pieces of data it needs rather than another endpoint needing to be created.
There is also Protoc buff by google that have type safety but thanks for the new video :)
What if my frontend is separated in other project? How cant I import the AppRouter?
You would want to have the type of AppRouter as a module you can consume at those other front ends
Great video thanks for help me finally understanding trpc
Amazing content man
As always, thank you, Kyle.
Content is as usual its Awesome.
I have one suggestion to name your title of videos.
You're such a wonderful experience developer.
Everyday in tech world people introduce lot of technologies.
They put effort and release that technology not downgrade any
existing technologies. Everything is a tool and people should upskil
enough to apply in right problem.
This is how we did it BEFORE rest. This is literally going backwards to the days of GWT/jsp/jsf only we've replaced Java with TypeScript.
If you think this replaces rest, you don't understand rest.
How did you do you have end to end type safety including your front end JavaScript?
@@thekwoka4707 GWT essentially compiles Java to JS. Much like TS there were integrations w/native js libs for the types, etc.
Obviously, it was only certain packages, you can't suddenly do files and sockets on the client. Theat means you had to notate which code was server vs client despite being the same language.
GWT also included widgets so you would add an ActionListener to a Button, etc. much like writing a rich client in Java.
Thanks Kyle! đ
My question is, when I pack my front end code with, for example webpack, will the routs from backend also bundled in the front end build? Because the front end code needs the definitions of typingâs and when yes how much will increase the front end bundle?
Soo... if you have more than one client calling api, is it possible to use tRPC ? Asking because tRPC requires types import from server to client, which is not possible when you have standalone APIs.
And even if you have server/client in same project, when you need to call third party APIs, you will still need to use good old REST. Which means inconsistency for your project.
Please, correct me if I'm wrong.
I was not subscribed to the channel all these years and almost never missing any upload? I don't believe that
Dude, REST and GraphQL are going to rule for a long time.
Thank you Kyle, God bless you!
Regarding the camera - I recommend, however, to make it a little smaller, and if it interferes with showing the code, you can turn it off (anyway, we all look at the code, not at your smiley :D)
In moving from XML to JSON, we tossed out one of XML's strongest features, document validation. You could define the types of values in the XML Scheme Definition (XSD), and validate an incoming XML document instantly. Now get off my lawn âč
Yeah I remember hating XML and SOAP when I first learned it. Now I actually miss it.
The same can be done with JSON. There are a lot of JSON schema validators for this.
why not share a types.ts file between client/server to enable type safety?
Cross type safety is cool. Monorepos and locking TS for all front facing services are big downsides through.
Great video! Correct me if I'm wrong but this only works in a monorepo? If you have 2 separate repositories for back and frontend then it doesn't help you.
So tRPC only works is your client and server applications are on the same repository?
What's about that?
How do you import the types of your server from the client?
Making a request for the types?
A full stack project with tRPC ! đ
Without using any monthly payment plan just fully free working project.
I haven't worked with any company that has the server and client both together. Normally, they're on different projects. So, GraphQL or REST is still better.
Damn I remember when Theo spoke shit about you when he was still growing up as a CZcamsr. I was hoping this was your turn to tune him. You're an overall better dev and person than me
What did he say?
Nice content. Didn't know tRPC. Mind note for tRPC => tool to build your SDK easier
If you are using typescript in the frontend and backend, trpc is the way to go clearly. For everything else rest or graphql are your options
or grpc
Typescript is possible for GraphQL. There are already code first approach in recent years.
@@arvi8843 of course you can do graphql in typescript but trpc itâs the better approach
I think both graphql and tRPC fails when we need good caching. Sure they can also utilize cache, but then need more effort. When caching is not that so important I think tRPC is a great option. Thank you for these great videos.
nice tech stack, cool
Mailgun for sponsoring this video so REST API and GraphQL will not die since they don't need sponsorship
Watching this video you might think why do we even have dynamically type languages where you don't have to declare the type and how does that affect type safety? Dynamic typing is found in scripting languages such as Python, Ruby, and JavaScript, and was invented to allow for more rapid prototyping and scripting of small projects. These languages are often used in situations where the exact structure and size of data is not known in advance, and where the ability to change types at runtime is valuable.
OpenAPI Specs and API generators is the way to go!
It sounds like a lot of overhead for very little benefit tbh, since the problem it solves not only will still exist for any external calls, but also can be solved very easily by running regular contract tests.
how we can separate backend and frontend here?
how to import router type in a react app?
We've made a full circle.
10 years ago the consensus was that REST was the right way to replace the outdated RPC.
We switch from SOAP (with wsdl) to REST, then graphQl arrives, without taking place of REST as REST took place of SOAP et now we go back to the start... but as i understand, it works only on monolithe app ?
Monolith AND monorepo :) Client and serverside code needs to be connected to get the typesafety benefits
@@cahva2 howvee, you could also provide the AppRouter type as an importable type to any kind of project.
@@cahva2 I was trying to work out if it was possible to inject "t" in to services , but not cracked it yet.
What if i want to use api from other language?
Imho hasura+graphql-codegen is unbeatable combo. What a pleasure to work with
How can we exchange type of AppRouter. I mean by Simply loging the AppRouter and create type in our Front End app?
Next video title đĄ: ChatGTP is this the end of Web Dev Simplified?!?
What if the client lives on an other project?
Very useful video and I watched your tutorial. The problem I see (or haven't been able to solve) is that today, middleware can exist in separate projects and be hooked in app.use quite easily.
app.use(userAuthService.initialize());
app.use(captchaService.initialize())
etc etc.
because middleware depends on
const t = initTRPC.context().create();
t.middleware( BLAH )
and t can only be defined once, I am struggle to see how you can modularise projects.
Maybe I'm missing something.
You notice kyle 's camera radius is growing every single time đđ
One question: there are many react clones of popular websites tutorial on youtube, can we code a clone and add to our public github repository ? I don't want to use it for any business or sell it to somebody. I want to use it just to get job, that shows my skills, so is it illegal to code for example google clone and add it to my public github repository?
What if the trpc project is a standalone project ? How do we go on getting that type safety across multiple UI apps ?
Is there a way to expose the typing alone ?
U trolling with that 13:47 :)
do we have to keep client and server in the same repo if we want the intellisense?
Great question, this is where the T3 Stacks helps out with. It makes it to where we can have everything from the front End to the back end in the same repo / folder
Nope, just need the type
Thanks for sharing this. Openapi also helpsâŠ..
Thanks
Thank you
I really want to see more support in backend frameworks for protobuf. With protobuf you can get that type safety through code generation and you get a much smaller payload. I'd really like to see efforts to make it a first class citizen in REST APIs but sadly it seems to be much more tightly integrated into gRPC (makes sense, they're both Google products) and nobody wants it in the REST world.
Protobuf has nothing to do with communication(gRPC or REST). You have to use protobuf for gRPC but you can use protobuf without gRPC.
@@wralith I disagree. I think content encoding is important to consider when considering what type of API to build. Protobuf is a major improvement in data encoding. If there was first class support for protobuf in most backend REST frameworks, more people would use it there, but there's not, so it's relatively limited to gRPC APIs.
Can we just use typescript web assembly in the frontend? Just typescript and skip the zod and use whatever back end you want. Java, python, rust, c++, etc
Do you use mailgun to send us those weekly newsletters?
please share your guitar link, I wanna purchase it!
Reagarding the USER const, using uppercase variables indicates that it is constant. Do not modify the contents of an uppercase variables.
Shoutout to SOAP web services
I am frontend developer, I haven't proper knowledge REST API and GraphQL, So at situation may I learn tRPC?
i use to loved graphql though. i used it for lots of my projects. with all of that, i realized it's cons. now i just used tRPC, prisma and react-query. it's not perfect, but at least closer to what i want things to be.
I pity the devs who will have to deal with your code in 10 years when all those frameworks and tools will be forgotten.
@@Kiev-en-3-jours yeah, it's the tech and tech are always changing. which is quit frustrating and exiting!
@@adimardev1550 wow I am speechless. By okay... It's the tech. Have fun following the trends.
@@Kiev-en-3-jours no, i mean oviously that's not what I mean. companies with legacy codes are desperately hiring none stop and lot's of people are taking those opportunities where most of us are struggling in this over saturated niche. and only few people knew this strategy which also caused an imbalance. this might also be the effect of influencers for the newbies.
So for small projects that are not using "micro" services or front-ends. Meaning on different repos due to the size of each service/ui.
Seems decent for personal projects, but does not scale well.
..or use monorepo. Size of the project does not matter
I 100% agree with you in general.
But Owners/Leads/UAT/QA/Devs might not like when one User Story (US) of the whole project has errors in it, so other US have to be backed out also that might not have had any errors.
Yes, this does happen.
Yes, this is mostly a waterfall issue, but it is not limited to it.
You don't need them in the same repo, you can export the type of AppRouter as a package to any consumers to create their own trpc clients from.
That is nice, hope it would work in something like C#, Java, ETC...
Again I think this is great for small projects.
For large projects there is a chance you will not be the FE, BE, and DB dev.
In that case I am not sure how helpful it really is. Some examples
Examples all TS expects {someDate: string}, simple example
-API {some_date: string}
--In this case it is either a five second change or a convesion during integration
-API {someDate: Date}
--Still will have to do some conversion during integration
-API [{someDate: string}, etc... ]
--Maybe you were not expecting this, but seems relatively like the first
In all cases FE, BE, and DB devs should be in contact with each other anyways. Cause maybe the data does not make sense or something else.
tRPC is not going to solve the above, there are also things like Swagger. Yes, tRPC and GraphQL might help the dev. Again you do not always have a mono repo and a change in one repo is going to require a change in another even if you can hook into AppRouter regardless.
PS: I am not even against something like this in larger/(not in your control) projects. Just seeing a few issues with it that make it not as great as it could be. If it could solve having to talk to other DEVs, then it would be super great but it can not.
â@@thekwoka4707ohh nice. Is it automated though? Do I have to manually install the package on the frontend every time an API change is made on the backend?
TRPC is great for monorepos purely built on TS. I don't see how it can be used in companies with microservices written in different languages. GraphQL is still great for letting dev fetch relational data without having to build an API for each combination of entities they want to fetch.
Why not just use swagger and generate your SDK with yaml/json file?
Can it be automated?
Wouldn't it be great if it also generate REST endpoints and documentation đ€
I see it creates type safety if you use client and server within one project because it has access to the server code when editing the client code.
What if I want to access an API provided by someone else? Does it also provide type safety there? How does that work? How does the actual interface protocol look like? Is this something readable as the JSON used in REST? Are types embedded into the interface? Or does it have a interface description like the WSDL of SOAP?
Is this also available for other languages besides JavaScript?
Take a look at TS-REST docs. I believe it's the middle ground to this use case
Hasura + graphql-codegen is way to go
All any consumer would need is the type of the AppRouter.
The client does not need access to any of the serverside code, only the type of the AppRouter and they can make a new trpc client.
New video: is RSC and Server Actions the end of tRPC?
from what I read, trpc is only exclusive for typescript. so trpc will not end rest / graphql.
other programming language can use rest / graphql / rpc
It's amusing watching devs get excited about 40 year old tech. I'm hoping this is the beginning of the end for REST, and hopefully GraphQL too. Also... nice video.
Youâre not talking about the cons of tRPC :
- canât upload files
- need a monorepo/monolith for types, you canât separate backend and frontend
- require JavaScript on front and back
Go with NestJS if you are working on a company project, you have an auth system, queues and everything ready for you with REST endpoints.
Many thanks for explanation! You definitly should try to make RAP))
`const client = createTRPCProxyClient` this is weird, you're telling me that you need the AppRouter type from the backend repository which lives somewhere on mars, and our frontend code lives on earth. its really weird that the client needs actual backend code in order to make it work instead of an API call.
not sure why your repo would need that, but its the same problem with exposing my service layer and creating middleware. it all exists in separate projects today and TRCP seems to depend on t. I haven't been able to figure out injecting this either.
Does tRPC solves the over-fetching problem?
web dev simplified fr
CZcamsrs need to stop saying âTypeScript is a type-safe language.â No, it absolutely is not. It just gives you an option to add static typing allowing for better compiler checks, tooling enhancements and the like.
make a tutorial with react+trpc :)
Trpc isnât language agnostic, have to use Node/TS for server. I want something more performant like Go
good with monorepo
Well, if you think this is better then GraphQL, you never worked with Apollo Server and Nexus. Self building types using Code First and for Client side you can use GenQL GraphQL client as query builder using type safe. Even more, i coded my own generator to use prisma directly from GraphQL. Where, skip, take, orderBy, etc, etc. You cant do anything of that using tRPC.
You don't think you can create your own Prisma generator for this?
Thing is, everything you've done is in NodeJS. NodeJS is not the only language of communication or of backend or of the client. Server comes in many forms and languages. What if the server is written Golang? What if the client is in Rust? I see tRPC offers a solution only in NodeJS. This is ... very very bad.
GRPC offers a variety of solutions for all these cases and it's already well integrated in IDEs with many plugins and already offers good solutions for client/server.
GraphQL does too and it's easily lintable and usable by frontend as well with errors when you use it incorrectly too.
edit:
tl;dr; I dont see any advantages over GraphQL or GRPC. Both are much more powerful in everyway I can imagine. More libraries, more capabilities.
It is as the end of graphql as graphql being the end of rest
I am using REST and just waited for GraphQl to die and now will wait for tRPC to die too
If GraphQL didn't end REST, this one won't end it too, hehe. Heck, We're still using Cobol, haha.
I'm pretty sure tRPC uses REST under the hood lol
When both Front-end and backend are written in typescript, it is working. Else sorry, sir.
Consider dart!
Wow I hate titles like this.
adblock 24/7 will make you feel better