tRPC, gRPC, GraphQL or REST: when to use what?
Переглядів 61,828
Рік томуIn this video I'm explaining how tRPC, gRPC, GraphQL and REST APIs work, how to choose the right one and common best practices and pitfalls.
======⚡⚡⚡======
👉 Host your website for under $2 a month: namecheap.pxf.io/c/3137064/62...
======⚡⚡⚡======
🙌 Become my Patreon and get exclusive perks: / softdevdiaries
💼 Follow me on LinkedIn and drop me a message if you'd like: / gusgadirov
💻 Also, let's connect on GitHub: github.com/gusgad
📚 Resources:
gRPC explained: • What is RPC? gRPC Intr...
GraphQL error handling: • GraphQL Error Handling...
And don't forget to subscribe for more videos like this 😊
@613fredp 4 місяці тому
Thanks for the informative video - when describing REST folks often forget about using ODATA REST endpoint which gives you additional features such as selecting the fileds, the number of records (limit) using query string arguments giving you one additional query layer rather than having to create a bunch of rest endoints in a standard way. The ODATA query params syntax is somewhat ugly but there is editor tooling and plugins available. I mention this because although not as granular as using QL it accomplishes alot of the same requirements
@mikhacavin Рік тому
finally i understood about how TRPC, GRPC and GRAPHQL works & the concept. great video !
@SoftwareDeveloperDiaries Рік тому
Happy to hear!
@nicolascosmefernandez9197 2 місяці тому
Wow thanks, very well explained! Keep it up you do a great job.
@user-rw8rn2zc7j 11 місяців тому
this is awesome please never stop posting
@SoftwareDeveloperDiaries 11 місяців тому
Will do so!
@s1dev 9 місяців тому
awesome content, thanks!
@khari_baat Місяць тому
Great video. Regarding GraphQL: You still have to write the code to get all the data. I think it should be made clear in the video.
@manoj-k 11 місяців тому
Very well explained ❤
@axel_huth Рік тому
i already knew everything but could never have explained it so well. huth ab ;)
@SoftwareDeveloperDiaries Рік тому
Hahah thank you bro 🤗
@Rafa_informatico 7 місяців тому
Not against GraphQL but, in REST you can reques specific fields if you implement filtering (extra parameter for listing the fields you want) and you can get data from other nested resources if you implement extension (extra parameter for listing the objects you want to be extended instead of returning only their Ids). And both patterns can be combined. That also gives you the control on which of those you allow.
@ilyboc 5 місяців тому
But that’s limited. It would be complicated for deep complex queries.
@TON-vz3pe 4 місяці тому
Yeah, these guys did not work in middleware integration tools. They easily underestimate REST.
@shubham320 3 місяці тому
So if rest already have querying facility, why do someone needs graphql?
@trumpetpunk42 3 місяці тому
@@shubham320good question!
@trumpetpunk42 3 місяці тому
That's OData, right?
@uchoatran1917 Місяць тому
Thanks, well explained.
@user-rd1eg5et2f 9 місяців тому
Amazing informative important video !!! You're amazing.
@SoftwareDeveloperDiaries 9 місяців тому
You too, my friend :)
@sajidrajput317 5 місяців тому
Great video... I love it
@Pareshbpatel 10 місяців тому
A very clear and succinct video on the pros and cons of using tRPC, gRPC, GraphQL, and REST for client/server communication. Thank you, Guseyn {2023-06-28}
@SoftwareDeveloperDiaries 10 місяців тому
Thanks for the feedback! :)
@VincentJenks 8 місяців тому
Seems like gRPC carries the least amount of risk. Less complexity than GraphQL, faster and simpler to reason about, and the highest compatibility across all client types. I can’t get myself psyched about GraphQL, after taking a full course on it and completing a couple corporate projects with it. It just doesn’t do much for you. Another set of schemas in your stack, and you still have to do all the heavy lifting on the backend, on requests. It’s not like it eases the burden of querying your data. It’s decent for integrating disparate services, but it comes with weight and complexity.
@SoftwareDeveloperDiaries 7 місяців тому
Agree!
@sourishdutta9600 Рік тому
Can you create videos on microsecice communications with grpc. Best practices and all.
@SoftwareDeveloperDiaries Рік тому
Sure, I’ll put it on my list :)
@marcialabrahantes3369 3 місяці тому
gRPC and sub-masks for nested data :)
@shobhavenkatesh6200 6 місяців тому
I have currently learnt the MERN stack. Your video is really informative, but as beginner I am not understanding which one to choose and learn. Can you please tell me which one to learn among grpc, trps and graphql.
@SoftwareDeveloperDiaries 6 місяців тому
I would suggest to learn ins and outs of the HTTP protocol and building REST services first. I have a video on REST too :)
@shobhavenkatesh6200 6 місяців тому
@@SoftwareDeveloperDiaries Thank you for guiding 😊
@abdulazeez.98 Рік тому
Very good points. tRPC is awesome but it’s kinda risky to stick with just typescript. Mobile apps (android and iOS) doesn’t support it. I have built a project with REST api backend and I’m thinking of replacing it with GraphQL. My main concern is the complexity, I guess I can’t have them all XD.
@SoftwareDeveloperDiaries Рік тому
Thanks for sharing your experience, I wasn't aware of that! Is your REST API getting too big or what's the reason behind replacement? :)
@abdulazeez.98 Рік тому
@@SoftwareDeveloperDiaries Thank you for the reply. Yes it is getting a bit too big, but the main problem is syncing the changes (and types) between frontend and backend. For every change in backend I need to remember (or check) exactly what it returns and reflect it in the frontend, this is a bit unreliable. I also do not like the way REST works. I sometimes find it unintuitive when I want to invoke a specific action in the backend (rather than just CRUD). GraphQL makes more sense. But for me it is not only about how difficult it is, but also modifying the current code to use it.
@kamalkamals 11 місяців тому
trpc it s not good for big project.
@gransmistad323 8 місяців тому
@@kamalkamals You should explain why.
@kamalkamals 8 місяців тому
@@gransmistad323 the creator of trpc said that when I ask him in the streaming about version two was out
@ignatiusn9851 Місяць тому
how do the above compare with tech like Kafka?
@naumanjabbar1877 Рік тому
why i will get all user data in rest ? the way we send fields to fetch in graphql , the same way i can send fields in rest api and obvioulsy api woul be getting data from db and it will get only those fields not all the data , overfetching and underfetching can be easily can be solved in rest like graphql . Any solid reason instead of typechecking to use grqphql over rest ? because overfetching and underfetching is not the reason , we can easily do that in rest also, send field name when requesting and from db only get that field and return ? So please help me to understand it better .
@SXsoft99 10 місяців тому
a lot of languages, especially strong typed languages, have a bit of a hard time with dynamic responses on REST because most devs write a response map object that is converted to json, also you risk ending up with a spaghetti response because it's not respecting response integrity
@dipteshchoudhuri 10 місяців тому
If you are sending field names, then you might as well use graphql.
@xBodro 10 місяців тому
Because it's no longer rest
@elina6969 9 місяців тому
Because then you're reinventing a worse GraphQL
@edhahaz 9 місяців тому
The actual reason to use graphql is supporting outdated clients. Infinite backwards compatability is probably why facebook created graphql and other stuff is a meme.
@fcnealvillangca7943 2 місяці тому
I choose rest API for my personal projects and sample works coz it's battle tested I'll just adjust when I work in a place where GraphQL, TRPC, etc etc use it. but what do you recommend?
@SoftwareDeveloperDiaries 2 місяці тому
Depends. If you're building personal projects that you can later show on interviews, then trying out other technologies wouldn't hurt. Otherwise, use what you're most comfortable with :)
@WantMore-mc8dx 9 місяців тому
Isn't Open API also strongly typed via the Swagger stuff?
@SoftwareDeveloperDiaries 9 місяців тому
Open API and Swagger is basically just a documentation. So doesn’t really deal with the application layer and doesn’t lead to a typed codebase.
@rajatarora8693 Місяць тому
One thing I am unable to understand with help of DynamicSerializer in DRF I can easily replicate GraphQL with REST, so why to use GraphQL?
@_thehunter_ 8 місяців тому
long live REST
@prodigy116 10 місяців тому
I think you can just specify the ID in REST so you only get the data that you need so you won't overfetch?
@SoftwareDeveloperDiaries 10 місяців тому
Yeah you can, to fetch the data for a particular user for example, but overfetching is about the data that comes along with that request that you can’t limit.
@613fredp 4 місяці тому
@@SoftwareDeveloperDiariesyes but if you implement a REST ODATA endpoint you can select only the fields and nested relationships plus their fields as well using query params (eg select / limit etc). Still though graphQL more granular but adds tech debt to teams without QL experience.
@mhasancoder 9 місяців тому
What about GraphQL and REST API combine and use, is it possible?
@SoftwareDeveloperDiaries 9 місяців тому
It’s possible but not recommended as it would result in a mess.
@MichelPascalHohmann Рік тому
Danke für das Video, können wir es ins Deutsche übersetzen lassen?
@szalaierik2 6 місяців тому
I am just studying GraphQL to widen my skillset, so not advocating for anything. But. Neither "overfetching" and "underfetching" nor not using subresources are good points against REST. Those are solved easily and supported by (probably all major) frameworks (I am only using Spring). Also I do not want to comment on the toxic teamrace you mentioned, but it is definitely not a REST problem.
@ruslan_yefimov 5 місяців тому
It's not even a problem anymore if you go with RPC :)
@ZorakWars 4 місяці тому
grpc has no need for a monorepo. Maybe the schema definitions for all APIs between the client and server can exist in a single repo, but the implementation of those APIs can be in separate repos. Look to see how Lyft uses grpc + Envoy for microservices without monorepos. Also backend language does not need to be the same javascript as front end. grpc schema is language agnostic.
@tgwutup 2 місяці тому
A visual aid would help solidify the concepts in this video. The information is explained well, otherwise.
@neo1017 8 місяців тому
{"status:200, "message": "I am OG................... ...................... User !" }
@jakemonton528 8 місяців тому
I don't agree with the 99% of the time you have to modify your frontend as well if you've modified your backend. That seems to me an architecture problem and doesn't correlate directly to REST. Frontend and backend devs rivalry seems like a company culture issue and doesn't directly relates to REST. Fetching a specific data via REST is fairly easy. You can use filters if you want to. Again, this falls down on your architecture and not necessarily because of REST ability to support this kind of stuff.
@cephaspeter842 7 місяців тому
Sometimes when you need to scale, and your data models needed for scaling differ from original architecture
@semenivanoff8615 4 місяці тому
It is exactly what happens when there is no architect on the project and systems designed by developers
@semenivanoff8615 4 місяці тому
This choise is to be made by architects, not developers. Developers just implement
@domfarr2968 9 місяців тому
99% of the time? What? 🤦♂️
@user-qr4jf4tv2x 10 місяців тому
forget graphql
@andgate6204 5 місяців тому
Graphql is easily the worst tech you can invest in. Well, other than rust.
@dennisk648 11 місяців тому
The problem, which graphql solves is really made up.
@SoftwareDeveloperDiaries 10 місяців тому
Fair enough 😀
@semenivanoff8615 4 місяці тому
Whaaaaaaaaaaat? In Rest when back changed, front should be changed as well?!! Whaaaaaat? Have you heard about contracts concept?! The whole idea is to offer service agreement that back offers. If this happens you have shitty, not poor but shitty architecture man. Replace your architect
@dorb1337 11 місяців тому
Amazing informative important video !!! You're amazing.
@SoftwareDeveloperDiaries 11 місяців тому
You too!
로운이네 가족일기 Rowoon's Family Diary
Переглядів 96 млн
Настоящее Время. Док
Переглядів 9 млн
Hard Play
Переглядів 18 тис.