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

look I would totally understand if you tell me that you're just a bit overwhelmed when it comes to building client and server-side communication because we have so many options at our hand and let's take a look at which one of them would fit your case the best so we're gonna start with the rest architecture and the important Point here is that it's an architecture it's not a protocol it's not a schema it's not a language it's an architecture and it's OG OG stands for Original Gangster but what I mean is that everybody's familiar with it because it's very similar to object oriented programming so for example you want to fetch the user data you can have users in your URL and if you want it to fetch the specific data of a specific user you put user slash ID and you fetch the data for this so what are the good things about rest apis well the reason they're so widespread is because they're so easy to build so a developer can build a rest API in a minimum amount of time the problem about the rest API is that they don't scale that well so they create this coupling between the backend and a client so whenever the backing changes 99 of the time the client also has to change and vice versa and from my experience if you have a separate back-end team and a front-end team this kind of crew creates a toxic rivalry between the teams because each team has to adjust to other team's requirements another important problem with rest apis is the thing called overfetching and under fetching for example when you're fetching the user data if you want to fetch only the age of the user but the user object is Big you're gonna get all the data of the user you're going to get the name you're going to the surname you're gonna get the profession but you only want the age so it's not easy to do that you would need to create a new endpoint and vice versa under fetching if you need more data you need to go and edit your API to supply you more data if you if your client needs more so you see this so what can we do here obviously try something else namely graphql graphql is not an architecture is not a protocol it's a query so ql stands for a query language and the cool thing about graphql is that it eliminates this under under fetching overfetching issue so you fetch only the data that you need which is pretty neat also this creates kind of a contract between your backend and the front-end team because you define a pre you have a predefined schema by which you're able to supply your client data from your API just by looking at this example you can see that on the right when we have a rest client you have to do two multiple requests to fetch for first of all the the album assets and then you need to supply a nested idea while on the left side we can see that you can do all of these two things in one query which in fact saves us the bandwidth so we don't have to replicate our endpoint and let's say if for example you had a website and a mobile app that they can talk easily to one endpoint and in case of rest API your mobile app always needs less bandwidth because you care about every extra kilobyte that you're fetching especially if it's some kind of an edge device eyes like refrigerator you really care about your data that you're fetching versus the website so it's really hard to implement this in rest and most likely you're going to have to develop new end points for your mobile app and your website so that they're talking in parallel but with graphql you can overcome this issue easily because you can easily determine which Fields you need from your API okay so what are the downsides of graphql I could identify one big downside from my own experience is that it's very hard to get graphql right if there's one condition that you have a a really good graphql Guru in your team who knows a lot about graphql or maybe that's you then go for it because as long as you have a good schema defined on your back end as long as you have set up everything well on your content your graphql communication will be perfect but I've seen teams doing this wrong and another downside of graphql that I personally ran into is the graphqls client libraries like Apollo they're very complicated and very hard to get them right they have to eat their own built-in caching system with write query and so on so just to make an inordinary HTTP request you have to write a lot of Border plate code and since it has its own built-in caching system which doesn't play that well with your browser's native caching system you usually run into weird bugs so bottom line when should you choose rest apis versus graphql if you have a very complex data representation let's say you have a users then your users can have playlists players or plays can have assets so a very big nest object data objects that they're that you're sending around go with graphql it's not easy to do that with rest and you're gonna end up with a lot of overhead if you care about bandwidth so if you have mobile users or if you have some Edge devices that care about every kilobyte transferred over the network go with the graphql because you can select specific data that you want to page if you're a startup that needs to iterate very quickly and you need to be able to find develop first very easily and you don't have much time go with the rest okay now what is trpc then well RPC stands for remote procedure call while T simply adds typescript to it now before we continue a quick word from our sponsor namecheap I thought I've already told you about this but apparently I haven't so I'm gonna have to tell it again I'm sorry you can host your website for under two bucks a month yes and this is real so on top of that hosting you're also gonna get a SSL certificate which means your connection with the server is going to be encrypted you're gonna get a 20 gigabytes of space on your disk you're gonna get a 24 hour customer service and a free domain how cool is that if you also agree that it's cool then do we have a deal well if you're still not convinced here's the thing you can get a 30 day money back guarantee so if you don't like it you can get your money back now I guess we have a deal right and now back to the video the main idea behind trpc is that it brings Bracken and the front end much much closer to each other especially if you're using JavaScript in your server and the client namely typescript so behind the scenes imagine your server has route and controllers that are responsible for handling routes right in your normal express.js app this is how it works so in trpc your client is going to be able to call exactly these controllers as if it was one application so they're really coupled to each other and on top of that you have a typescript which adds a schema so there's really no way of supplying wrong data from your client to the backend because there's typescript that defines it exactly typed schema for both of them and usually when you're using trpc it's very common to use a mono repo if you already have a model report you're lucky and if you're using typescript and on both of your ends you're lucky otherwise try to use a monody before trpc because your client is going to be able to import exactly the same schema that your backend has defined and Sim simply call it so otherwise if you have a rest you can slowly migrate it but if you don't then it's up to you whether you want to rewrite your application to trpc so what are the advantages of trpc apart from the fact that it's strongly typed so trpc runs on top of HTTP 2 and it has a lot of out of the box optimizations and capabilities that's going to make your code unique and very close to each other so this is definitely not a nice thing and it's very lightweight compared to graphql of course another cool thing is that your IDE is automatically going to be able to to redirect you from your content code to your backend if you press Ctrl right left click on one of your functions that you're calling from your front end I'm going to make a separate video going into details of trpc and looking into code and how it can work with react in another separate video that's going to come out in a week so make sure you subscribe if you're interested also trpc has a much lower bundle size and it doesn't suffer from this bulky packages that graphql forces you to install on the client and your server so when should you use graphql versus trpc trpc unfortunately does not fix the problem when you need to request only specific data from your API so if you have nested data and complex data you have to go with graphql if you're caring about your bandwidth you have to go with graphql and when should you choose rest versus trpc well if you're already using JavaScript on both of your ads and especially typescript you can go with trpc and last but not least grp is in here we replaced t with G and G here stands for Google so Google remote procedure again it has the same concept as trpc which means they're gluing your client to your server and your client is able to invoke specific functions of the server as it was one application and also grpc does not work with Json it works with its own binary format called protobuffer it makes some things a bit different so first of all jar PC really requires the client to tap into its HTTP 2 capabilities because grpc really works much faster than anything else but modern browsers even the modern browsers are still not able to do that so you need to install a grpc web package to be able to do that but if you need your PC simply for your microservices to talk to each other grpc is the right way also you can use grpc over trpc if your microservices are written in different languages for example in Java in go and node so you're not only limited to typescript and you can still use the same functionality that remote procedural calls give you this idea was actually already before we had rest API so it's an old concept rpcs remote procedure calls are not new but the thing is Google managed to really optimize them so if you really care about lower bandwidth because grpc is working with protobuffer and it's much faster to communicate and make transactions go with grpc if your microservices are written in different languages and you also need to make this communication between microservices optimized go with geography if you care about bandwidth and real-time streaming because grpc is able to do that go with the grpc but again it doesn't work as graphql because it's a completely different concept and also unfortunately grpc is not as mature as you would expect it to be maybe it will be in two or three years but at the moment of this video it's not I hope you liked the video if you did please smash like and feel free to write me in a comment down below I'm gonna try to answer it as always and I will see you in the next video

Channel: Software Developer Diaries

Views: 43,755

Keywords: software development, software developer, programming, software engineering, javascript, web development, coding, trpc, grpc, trpc vs rest, trpc vs graphql, graphql, graphql vs rest, grpc api, rest api, rest api tutorial, graphql schema, graphql apollo, graphql design, building rest api, building trpc, trpc tutorial, grpc tutorial, grpc protobuf, advanced trpc, trpc best practices, grpc explained, trpc explained

Id: veAb1fSp1Lk

Length: 10min 46sec (646 seconds)

Published: Sun Mar 19 2023