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.
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
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.
I think he made at least two mistakes in REST and gRPC talks: 1. In REST you do not need to under/over fetch. You can use query params. 2. In gRPC you do not need to use HTTP2. It's also mostly not supposed by reverse proxies, app gateways and so on. Correct me if I'm wrong please.
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
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.
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 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.
Ive seen geaphql just creat more problems. More glue code, more start services thay cost time, more security concerns. If it only works well when its set up perfectly it's really not gonna work well at many workplaces.
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.
Nice explanation! I think you miss some of the nuances, but that's rather difficult in these short informative videos. Some remarks I didn't spot in the comments yet: * If you create an external API, don't use tRPC/gRPC. It's not well enough supported when your users can pick any language they want. * Schema's can generate code for both the client and server. If you prefer code-first implementations you can usually generate a schema and use that schema to generate typings for the other side (client/server)
Some treats of all of these methods can be achieved just by breaking the standards of the other. For instance: use POST for reading and include the filter criteria in the body (GET should have a body BTW, this is one reason why I hate REST)
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 :)
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.
i would mostly still go for rest opposed to graphql. Examples you gave aren't super common at all. Also why the hell would u use trpc instead of just building a monolith at that point?
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}
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.
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.
U r sooo cool man... Loved it. Just subscribed... thanks. And u are also sooo charming, did u know that? Tnx for the free gem, plz keep up the good work
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.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
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.
This made me confused for the longest time. It's just a fancy version of REST in many ways.
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?
finally i understood about how TRPC, GRPC and GRAPHQL works & the concept. great video !
Happy to hear!
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
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!
I think he made at least two mistakes in REST and gRPC talks:
1. In REST you do not need to under/over fetch. You can use query params.
2. In gRPC you do not need to use HTTP2. It's also mostly not supposed by reverse proxies, app gateways and so on. Correct me if I'm wrong please.
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.
this is awesome please never stop posting
Will do so!
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
What about db query? Dont know about it ? Or dont want takk about it?
Cool, thats very clear explanation, thank u
> as long as you use it perfectly it will work (paraphrased, about GraphQL)
Strictly speaking this can be said or anything.
THANK YOU VERY MUCH FOR THIS INSIGHTFUL VIDEO.
how difficult is it to use tRPC with rust and wasm in the front so that tRPC can communicate via WASM and Rust on the backend?
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?
Can you create videos on microsecice communications with grpc. Best practices and all.
Sure, I’ll put it on my list :)
Ive seen geaphql just creat more problems. More glue code, more start services thay cost time, more security concerns. If it only works well when its set up perfectly it's really not gonna work well at many workplaces.
i already knew everything but could never have explained it so well. huth ab ;)
Hahah thank you bro 🤗
how do the above compare with tech like Kafka?
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 😊
Wow thanks, very well explained! Keep it up you do a great job.
Nice explanation! I think you miss some of the nuances, but that's rather difficult in these short informative videos.
Some remarks I didn't spot in the comments yet:
* If you create an external API, don't use tRPC/gRPC. It's not well enough supported when your users can pick any language they want.
* Schema's can generate code for both the client and server. If you prefer code-first implementations you can usually generate a schema and use that schema to generate typings for the other side (client/server)
Some treats of all of these methods can be achieved just by breaking the standards of the other. For instance: use POST for reading and include the filter criteria in the body (GET should have a body BTW, this is one reason why I hate REST)
A great overview! Thank you!
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 :)
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.
Why is Typescript on the server, who came up with that.
I don't understand why it's so common.
Why not? 😅
Thanks, well explained.
i would mostly still go for rest opposed to graphql. Examples you gave aren't super common at all. Also why the hell would u use trpc instead of just building a monolith at that point?
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! :)
Very well explained ❤
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.
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 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 :)
gRPC and sub-masks for nested data :)
A visual aid would help solidify the concepts in this video. The information is explained well, otherwise.
great explanation, thanks
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.
Great video... I love it
U r sooo cool man... Loved it. Just subscribed... thanks. And u are also sooo charming, did u know that? Tnx for the free gem, plz keep up the good work
awesome content, thanks!
apollo graqhQL for the client, grpc json on the server. That's it.
hot and smart. subscribed!
great video
GRPC: 08:33
g in gRPC doesn't stand for google...
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
Danke für das Video, können wir es ins Deutsche übersetzen lassen?
Love you too, bro.
Graphql is best.
No other protocol has solved bandwidth issues, underfecthing, overfetching issues.
long live REST
{"status:200,
"message": "I am OG...................
...................... User !"
}
99% of the time? What? 🤦♂️
forget graphql
Graphql is easily the worst tech you can invest in. Well, other than rust.
At least use PPTs ffs
Next time for sure 😄
The problem, which graphql solves is really made up.
Fair enough 😀
Amazing informative important video !!! You're amazing.
You too!