tRPC, gRPC, GraphQL or REST: when to use what?
Vložit
- čas přidán 18. 03. 2023
- 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 😊 - Věda a technologie
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
finally i understood about how TRPC, GRPC and GRAPHQL works & the concept. great video !
Happy to hear!
Wow thanks, very well explained! Keep it up you do a great job.
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.
But that’s limited. It would be complicated for deep complex queries.
Yeah, these guys did not work in middleware integration tools. They easily underestimate REST.
So if rest already have querying facility, why do someone needs graphql?
@@shubham320good question!
That's OData, right?
this is awesome please never stop posting
Will do so!
i already knew everything but could never have explained it so well. huth ab ;)
Hahah thank you bro 🤗
awesome content, thanks!
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.
Amazing informative important video !!! You're amazing.
You too, my friend :)
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}
Thanks for the feedback! :)
Thanks, well explained.
Very well explained ❤
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.
Agree!
great explanation, thanks
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.
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? :)
@@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.
trpc it s not good for big project.
@@kamalkamals You should explain why.
@@gransmistad323 the creator of trpc said that when I ask him in the streaming about version two was out
Great video... I love it
Can you create videos on microsecice communications with grpc. Best practices and all.
Sure, I’ll put it on my list :)
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.
I would suggest to learn ins and outs of the HTTP protocol and building REST services first. I have a video on REST too :)
@@SoftwareDeveloperDiaries Thank you for guiding 😊
gRPC and sub-masks for nested data :)
how do the above compare with tech like Kafka?
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?
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 :)
Danke für das Video, können wir es ins Deutsche übersetzen lassen?
A visual aid would help solidify the concepts in this video. The information is explained well, otherwise.
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.
long live REST
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 .
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
If you are sending field names, then you might as well use graphql.
Because it's no longer rest
Because then you're reinventing a worse GraphQL
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.
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?
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.
It's not even a problem anymore if you go with RPC :)
Isn't Open API also strongly typed via the Swagger stuff?
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.
I think you can just specify the ID in REST so you only get the data that you need so you won't overfetch?
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.
@@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.
What about GraphQL and REST API combine and use, is it possible?
It’s possible but not recommended as it would result in a mess.
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.
Sometimes when you need to scale, and your data models needed for scaling differ from original architecture
It is exactly what happens when there is no architect on the project and systems designed by developers
{"status:200,
"message": "I am OG...................
...................... User !"
}
This choise is to be made by architects, not developers.
Developers just implement
99% of the time? What? 🤦♂️
forget graphql
Graphql is easily the worst tech you can invest in. Well, other than rust.
The problem, which graphql solves is really made up.
Fair enough 😀
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
Amazing informative important video !!! You're amazing.
You too!