Is tRPC The End Of REST/GraphQL?

[@WebDevSimplified]

Thanks to Mailgun for sponsoring this video! Head to mailgun.com/webdev to try Mailgun today.

[@PaulSebastianM]

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

[@atuuuuum]

Java RMI all over aggain xD

[@tabliqatchi6696]

That's how people make money 🤣

[@charlie64x2]

This is why I still program in COBOL in 2024.

[@RedShift5]

Yeah we've gone full circle, we're doing server side rendering again.

[@ayandhara]

Graphql is very much more useful than trpc when client and server are two completely different apps (which is much more common)

[@thekwoka4707]

Why? You can have a shared package that has the trpc router type to use at multiple consumers.

[@petter9078]

There are monorepos coming for building web and mobile apps in one project

[@zzzyyyxxx]

@@thekwoka4707 you're assuming both are TypeScript. They could be two completely different languages instead, like Rust and Flutter, which is what in using.

[@hannad]

@@thekwoka4707 only in javascript land. people prefer golang over nodejs when when it comes to scale.

[@TypedefDev]

I like my types

[@gosnooky]

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.

[@RexGalilae]

Kinda being pedantic here but not necessarily the same application but the same monorepo. You could still distribute work between the FE and BE like with any other project

[@t3dotgg]

Hey this tRPC thing is pretty cool

[@arslanali774]

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.

[@metalsadman]

yep, even graphql didn't kill rest when naysayers that was gonna be the case when it came out.

[@metalsadman]

this is only good if you are solely doing fullstack and have control of both fe and be.

[@pablom8854]

@@metalsadman not true

[@qcmira2024]

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 !

[@Andersondns]

What if my frontend is separated in other project? How cant I import the AppRouter?

[@thekwoka4707]

You would want to have the type of AppRouter as a module you can consume at those other front ends

[@ilovenaturesound5123]

Very straightforward and easy to understand. One of the best tutorials over tRPC. Looking forward to the full tRPC project!!!

[@jfftck]

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.

[@DrinbevorBernd]

Exactly and than there is hardly a benefit when comparing it to well typed https calls e.g. with axios.

[@ghostlexly]

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.

[@kalideb-y3y]

thanks for this

[@Systemv1]

Thank you for this REST/GraphQL comparison. Super helpful!

[@_the_one_1]

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

[@arvi8843]

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.

[@Ilohimushka]

@@arvi8843 And how we import types from app router ?

[@ukaszzbrozek6470]

@@Ilohimushka You install a special npm package thet contains BE types.

[@EIsenah]

​@@ukaszzbrozek6470Is it automated? I'm confused how the workflow will be when changes are made on the backend?

[@sahilaggarwal2004]

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!

[@sujit_webdev]

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.

[@sahilaggarwal2004]

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

[@sujit_webdev]

@@sahilaggarwal2004 Yes, I agree with you totally! 👍👍

[@pablom8854]

u still using T3?

[@faizanahmed9304]

Need a full in dept tutorial on tRPC very similar to your ZOD tutorial(awesome tutorial). Please!

[@siya.abc123]

I was not subscribed to the channel all these years and almost never missing any upload? I don't believe that

[@Suresh-br2zz]

why not share a types.ts file between client/server to enable type safety?

[@noahdunbar]

SvelteKit offers endpoint typing out of the box automatically!

[@thekwoka4707]

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.

[@mariumbegum7325]

Very useful video! Looking forward to viewing more

[@jordcodes]

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.

[@faizul_official]

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.

[@eleah2665]

Thanks Kyle. I would be interested in a trpc tutorial. Between trpc and zod you are so safe you can .

[@pupfriend]

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.

[@OzShurki]

There is also Protoc buff by google that have type safety but thanks for the new video :)

[@MisouSup]

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.

[@milon27]

how we can separate backend and frontend here? how to import router type in a react app?

[@sachin_dev]

Was waiting for this. Thanks

[@sabuein]

As always, thank you, Kyle.

[@beautifulro]

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 ?

[@cahva2]

Monolith AND monorepo :) Client and serverside code needs to be connected to get the typesafety benefits

[@thekwoka4707]

@@cahva2 howvee, you could also provide the AppRouter type as an importable type to any kind of project.

[@daninmanchester]

@@cahva2 I was trying to work out if it was possible to inject "t" in to services , but not cracked it yet.

[@himalaygswm]

Dude, REST and GraphQL are going to rule for a long time.

[@noaffie]

tRPC is going to replace REST/GraphQL the same way MongoDB replaced SQL

[@Gardel1337]

Lol, I like the analogy

[@diegoavendanohernandez9908]

Great video thanks for help me finally understanding trpc

[@MikeCOYS]

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.

[@coder_one]

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)

[@mrkhoros]

Mailgun for sponsoring this video so REST API and GraphQL will not die since they don't need sponsorship

[@nikilk]

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 ?

[@coolemur976]

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.

[@LaLoses]

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?

[@JR7SQUARE]

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

[@climatechangedoesntbargain9140]

or grpc

[@arvi8843]

Typescript is possible for GraphQL. There are already code first approach in recent years.

[@JR7SQUARE]

@@arvi8843 of course you can do graphql in typescript but trpc it’s the better approach

[@salmanrana9478]

How can we exchange type of AppRouter. I mean by Simply loging the AppRouter and create type in our Front End app?

[@adambickford8720]

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.

[@thekwoka4707]

How did you do you have end to end type safety including your front end JavaScript?

[@adambickford8720]

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

[@cx123456]

We've made a full circle. 10 years ago the consensus was that REST was the right way to replace the outdated RPC.

[@imagineabout4153]

Amazing content man

[@thedevnoteyt]

A full stack project with tRPC ! 🌚

[@WarframeCrunch]

Without using any monthly payment plan just fully free working project.

[@wobsoriano]

New video: is RSC and Server Actions the end of tRPC?

[@SERV007]

Cross type safety is cool. Monorepos and locking TS for all front facing services are big downsides through.

[@ichbinder2323]

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?

[@waleedsharif618]

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 client lives on an other project?

[@DodaGarcia]

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.

[@deatho0ne587]

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.

[@cahva2]

..or use monorepo. Size of the project does not matter

[@deatho0ne587]

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.

[@thekwoka4707]

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.

[@deatho0ne587]

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.

[@EIsenah]

​@@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?

[@IronTeddyBear]

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 ☹

[@KeithGraves]

Yeah I remember hating XML and SOAP when I first learned it. Now I actually miss it.

[@AmitKumar-je7rn]

The same can be done with JSON. There are a lot of JSON schema validators for this.

[@Saruman_Kaz]

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.

[@theisoj]

Thanks Kyle! 👌

[@siya.abc123]

Damn I remember when Theo spoke shit about you when he was still growing up as a KZbinr. I was hoping this was your turn to tune him. You're an overall better dev and person than me

[@rod6722]

What did he say?

[@roshanlalsahu7846]

do we have to keep client and server in the same repo if we want the intellisense?

[@ak-loz]

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

[@thekwoka4707]

Nope, just need the type

[@ashtonmiddlefield9819]

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

[@UnderstandingCode]

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.

[@cangurcan99]

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.

[@de0vr]

Thank you Kyle, God bless you!

[@edisonarango]

OpenAPI Specs and API generators is the way to go!

[@gislo]

U trolling with that 13:47 :)

[@bl_int]

nice tech stack, cool

[@djblast101]

Next video title 💡: ChatGTP is this the end of Web Dev Simplified?!?

[@nisabmohd]

You notice kyle 's camera radius is growing every single time 😂😂

[@esportsnexus]

please share your guitar link, I wanna purchase it!

[@Kreshel1]

Nice content. Didn't know tRPC. Mind note for tRPC => tool to build your SDK easier

[@theotherguy102]

Do you use mailgun to send us those weekly newsletters?

[@The-Funk35]

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.

[@wralith]

Protobuf has nothing to do with communication(gRPC or REST). You have to use protobuf for gRPC but you can use protobuf without gRPC.

[@The-Funk35]

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

[@adimardev1550]

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.

[@Kiev-in-3-days]

I pity the devs who will have to deal with your code in 10 years when all those frameworks and tools will be forgotten.

[@adimardev1550]

@@Kiev-in-3-days yeah, it's the tech and tech are always changing. which is quit frustrating and exiting!

[@Kiev-in-3-days]

@@adimardev1550 wow I am speechless. By okay... It's the tech. Have fun following the trends.

[@adimardev1550]

@@Kiev-in-3-days 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.

[@salmandabbakuti]

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

[@daninmanchester]

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.

[@daninmanchester]

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.

[@yiyoja]

Why not just use swagger and generate your SDK with yaml/json file?

[@EIsenah]

Can it be automated?

[@outluch9286]

What if i want to use api from other language? Imho hasura+graphql-codegen is unbeatable combo. What a pleasure to work with

[@mamunahmed8113]

I am frontend developer, I haven't proper knowledge REST API and GraphQL, So at situation may I learn tRPC?

[@Nil-js4bf]

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.

[@exapsy]

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.

[@mustafa-ahmed-dev]

Thank you

[@Markus_753]

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?

[@gdsftvdr]

Take a look at TS-REST docs. I believe it's the middle ground to this use case

[@outluch9286]

Hasura + graphql-codegen is way to go

[@thekwoka4707]

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.

[@netssrmrz]

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.

[@bilza2023]

I am using REST and just waited for GraphQl to die and now will wait for tRPC to die too

[@photon628]

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

[@zlackbiro]

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.

[@thekwoka4707]

You don't think you can create your own Prisma generator for this?

[@rowolta]

Reagarding the USER const, using uppercase variables indicates that it is constant. Do not modify the contents of an uppercase variables.

[@milansingh3222]

Thanks for sharing this. Openapi also helps…..

[@GonzaloMassa]

Shoutout to SOAP web services

[@shaheerhashim10]

Does tRPC solves the over-fetching problem?

[@TypedefDev]

One problem with it is it doesn't support multipart/form-data

[@thekwoka4707]

Is that a problem?

[@TypedefDev]

@@thekwoka4707 not really, just something that would be cool to have. I saw a pr regarding this.

[@phamthao5421]

yes, did you find the way to use multipart/form-data ?

[@TypedefDev]

@@phamthao5421 In my case, I was uploading a video file to S3. I just created presigned url where you can directly fetch to.

[@phamthao5421]

@@TypedefDev I don't use s3 :(

[@moutafatin]

Wow I hate titles like this.

[@habiks]

adblock 24/7 will make you feel better

[@yaroslavozerov1121]

Many thanks for explanation! You definitly should try to make RAP))

[@tiboristheblackdog4354]

di ko panaga alam mag rest api at graphQL e.

[@kakun7238]

web dev simplified fr

[@dasten123]

Wouldn't it be great if it also generate REST endpoints and documentation 🤔

[@mr.random8447]

Trpc isn’t language agnostic, have to use Node/TS for server. I want something more performant like Go

[@vladislavseverin4055]

i say two words: code-gen

[@rishiraj2548]

Thanks

[@preetiam2180]

What about gRPC?

[@josersleal]

this is 10x more complicated than SOAP is. plus its 10x less safe than SOAP is. And more complicated. did I mention unsafe? Its stupid!

[@devkumar9889]

Why ? , when I plan to learn something new it gets end

[@dasten123]

Nothing gets end. It's just clickbait

[@Franczinator]

I don't see a ton of use for tRPC. Well designed APIs are versioned, and the endpoints and parameters should be immutable- or at least backwards compatible.