tRPC, gRPC, GraphQL or REST: when to use what?

Подписаться 24 тыс.

Просмотров 65 тыс.

50% 1

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 😊

Наука

Опубликовано:

18 мар 2023

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 83

@nicolascosmefernandez9197 3 месяца назад

Wow thanks, very well explained! Keep it up you do a great job.

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

@s1dev 9 месяцев назад

awesome content, thanks!

@user-rw8rn2zc7j Год назад

this is awesome please never stop posting

@SoftwareDeveloperDiaries Год назад

Will do so!

@Rafa_informatico 8 месяцев назад

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 5 месяцев назад

Yeah, these guys did not work in middleware integration tools. They easily underestimate REST.

@shubham320 4 месяца назад

So if rest already have querying facility, why do someone needs graphql?

@trumpetpunk42 4 месяца назад

@@shubham320good question!

@trumpetpunk42 4 месяца назад

That's OData, right?

@manoj-k 11 месяцев назад

Very well explained ❤

@khari_baat 2 месяца назад

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.

@axel_huth Год назад

i already knew everything but could never have explained it so well. huth ab ;)

@SoftwareDeveloperDiaries Год назад

Hahah thank you bro 🤗

@uchoatran1917 Месяц назад

Thanks, well explained.

@user-rd1eg5et2f 10 месяцев назад

Amazing informative important video !!! You're amazing.

@SoftwareDeveloperDiaries 10 месяцев назад

You too, my friend :)

@viplikeit 12 дней назад

great explanation, thanks

@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 8 месяцев назад

Agree!

@ignatiusn9851 2 месяца назад

how do the above compare with tech like Kafka?

@fcnealvillangca7943 3 месяца назад

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 3 месяца назад

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 :)

@shobhavenkatesh6200 7 месяцев назад

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 7 месяцев назад

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 7 месяцев назад

@@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 Год назад

trpc it s not good for big project.

@gransmistad323 9 месяцев назад

@@kamalkamals You should explain why.

@kamalkamals 9 месяцев назад

@@gransmistad323 the creator of trpc said that when I ask him in the streaming about version two was out

@sourishdutta9600 Год назад

Can you create videos on microsecice communications with grpc. Best practices and all.

@SoftwareDeveloperDiaries Год назад

Sure, I’ll put it on my list :)

@marcialabrahantes3369 4 месяца назад

gRPC and sub-masks for nested data :)

@tgwutup 2 месяца назад

A visual aid would help solidify the concepts in this video. The information is explained well, otherwise.

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

@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 11 месяцев назад

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 11 месяцев назад

If you are sending field names, then you might as well use graphql.

@xBodro 10 месяцев назад

Because it's no longer rest

@elina6969 10 месяцев назад

Because then you're reinventing a worse GraphQL

@edhahaz 10 месяцев назад

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.

@MichelPascalHohmann Год назад

Danke für das Video, können wir es ins Deutsche übersetzen lassen?

@ZorakWars 5 месяцев назад

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.

@mhasancoder 10 месяцев назад

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.

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

@_thehunter_ 9 месяцев назад

long live REST

@szalaierik2 7 месяцев назад

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 6 месяцев назад

It's not even a problem anymore if you go with RPC :)

@neo1017 9 месяцев назад

{"status:200, "message": "I am OG................... ...................... User !" }

@jakemonton528 9 месяцев назад

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 8 месяцев назад

Sometimes when you need to scale, and your data models needed for scaling differ from original architecture

@semenivanoff8615 5 месяцев назад

It is exactly what happens when there is no architect on the project and systems designed by developers

@semenivanoff8615 5 месяцев назад

This choise is to be made by architects, not developers. Developers just implement

@domfarr2968 10 месяцев назад

99% of the time? What? 🤦‍♂️

@andgate6204 6 месяцев назад

Graphql is easily the worst tech you can invest in. Well, other than rust.

@user-qr4jf4tv2x 11 месяцев назад

forget graphql

@dennisk648 11 месяцев назад

The problem, which graphql solves is really made up.

@SoftwareDeveloperDiaries 11 месяцев назад

Fair enough 😀

@semenivanoff8615 5 месяцев назад

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