GraphQL vs REST for Side Projects

so I've built and released two side projects now that used graph QL in this video I kind of wanted to reflect on what things I thought went well with them and what things I thought didn't go so well in regards to choosing graph QL so in this video it's kind of going to be a graph QL versus rest where I talk about the advantages that I felt were really nice when using it and some of the disadvantages of it so hopefully by the end of this video you'll have a good idea if you're starting a new project whether you should choose graph QL or rest for it so this this videos going to be kind of from the point of view of someone who is a solo developer or working in a small team and some of the things you could get from that so I wasn't doing micro services or a graphical gateway or any of that it was just a single graph QL server that I built out for this and I was the solo developer so I was both doing the front end and back end and full stack so that was kind of just the background of my experience with this so let's go ahead and jump into what I thought were some advantages of graph QL from using it so the first one this is one everyone is going to talk about when they talk about graph QL and that's there is no over-under fetching of data with graph QL so basically you can specify the fields that you want and get exactly those back which is very handy when you have multiple clients and different not even multiple clients but different pages that need different requirements of data there's so just to give you an idea of what I'm talking about this is one query that I have in my recipe project where we have cookbooks and sometimes all I care about is the name of the cookbook and so I will just request the name and I can do that like this and so I have some queries that look like that other times I need to know who the author of the cookbook is and whether the book was shared with other people and so I have this field called shared info where I can get the first name in the last name of the person who shared the author anyway so this particular field requires me to do a join in the database or requires an extra computation to get so when I don't when I don't need this information not how not showing it now requesting it is efficient so because of how graphic ql works you can be efficient and only do the computations you need but with that said it's more complex to actually set this up on the back inside which I'm going to get into when we get into the disadvantages but that's just one thing to note is that all right so the next thing is pretty handy and that's you don't have to version your graph QL API so basically you have a graph QL schema and if you use the REST API before you may have seen it looks something like this where there's version so you may have V one of the posts or V two of the posts you're requesting for example github I think is on v4 of the API BK and the reason why you have to do this is when you release a new version of your API not all the clients get the update right away same thing worked for me when I release my app on the App Store not everyone gets the same code on their phone right away it takes some time to roll out the update so there's gonna be some people on the old version some people on the new version and your server needs to support both of those users so with graph QL you can definitely still mess this up with your schema but if you're careful notes you're doing and you just add fields to your schema then both users that have old phones or the old version and new versions of stuff it can still request stuff from your API and then you just use different fields so for example if we had a new field on this cookbook called a new author field this was there you go new auth field I could select this on my new clients and that works fine it doesn't affect my old clients or old code because they don't need that field or whatever so that's one advantage there that has been quite handy because I don't have to think about that when I'm releasing new versions of my server I know if I'm just adding fields on it's not going to break any of the old code when I upgrade alright so the last advantage is just because it's a type system and it's checking the types of everything and it knows the types of everything there's some fun and fun benefits that you get from that so the first one is it just catches airs that you make so for example in my code when I'm making requests to different api's or different queries or mutations and I forget to pass in a variable or something it's gonna tell me right away and that's save some time that's a small thing but it's pretty nice the other thing is it's self documenting so even for myself if I'm just the only developer it's kind of nice to be able to go through the graph QL schema and the graphical documentation that gets created for you to see just a query it or I may have not touched a query in a while or a mutation or done something in a while and I can just go back and view what the stuff that I can what variables I need to pass in and what I get back from that so it's pretty handy even if I'm the only one working on it and if you're working with the fuel/air developers it's super nice to be able to share what information and how they can access the different end points and then the last one is the tooling that you get from this so I this is probably I would say the biggest thing that I've enjoyed about using graph QL is the tools that are now available because it is a typesafe schema or it's a typed schema that you're creating so I'm very happy with the code generated on the front-end so using a combination of graphical code generator and Apollo I'm able to just write a query like this and then is going to generate a react hook for me now and so it makes it very easy for me to write out my components very quick so this is what one of those hooks looks like this is a use my recipes query and it's very handy to integrate this with typescript and so I get type definitions that change as my server changes automatically and this is all generated from the server so now what I can do is I can type variables for example and I can see exactly what I need to pass in here so I need to pass something called options inside of options I have two different fields I can pass in a cursor and something called not in a cookbook which is a boolean and cursor is a string or null or undefined and so I know exactly what I can pass in here as values and I can get very productive with that and also just Apolo all the tooling that comes along with that that's built on automatically for you they're handling caching for you you can easily refetch data you can easily go in and start pulling the data if you need to I don't do that too often but just the information that they automatically give for you is super nice and so if I was building something with a REST API I think I would want to find a tool similar to what Apollo does or at least build out my own version that's similar to get some of this functionality because I've been very happy with it and very productive using it all right so that is pretty much the advantages that I noticed when using graph QL and I definitely would say the biggest one was the tooling and just the speed I was able to go once I generate the query and again I'm able to put whatever feels I need for my component and then I generate the hook using graphical code generator and then I go and use the Apollo component that's generated for me all right so now let's get into the disadvantages so the first thing is it's kind of more complex to fetch and get everything working efficiently in graph QL so I talked about earlier about how we have this shared info field and sometimes I want the first name in the last name and sometimes I don't so what that means is in my code when I resolve and make this work it's a little bit more complex to do that and to do it in a way that's efficient in the backend and I'm not just hitting my database with a ton of requests and so there's tools to help you out with this you may have to use something like data loader to get this working efficiently and there are some tools that are out there help combat this but it's something you have to note and you have to spend some more time with it so you can use something like Prisma Asura post-grad file app sync and there's probably other ones as well they can try to help you out with making this process easier and a lot of this has to do with when you're fetching relationships in the database and getting that data in there all right so next thing is it's harder to cache and rate limit stuff so this is something where I didn't feel this one as much I didn't feel like it was as hard to cache things another thing to note if you're just working on I project you may not even have to deal with either of these two things at first so that's something to note as well but when a lot of people bring up this point caching they have they're talking about if you're caching using something like a CDN and I think a lot of times you're gonna end up caching using something like Redis anyway and so caching isn't not a whole lot different with graph QL than with a REST API if you're using Redis or something like that and so I wouldn't say it's that much harder to cache and graph QL then it is in a REST API but I will say rate limiting is harder there's also other problems where now people can do arbitrary queries and they can arbitrary query any number of fields and any number of times and so you kinda need to have a system in place to handle that and to what happens when someone requests too many fields how do you know if they've requested too many fields it's kind of there's some tools in place that you can use to handle some of this stuff but because you're letting the user choose or the client choose what fields are being requested it can you don't know ahead of time and so it is arbitrary and unknown and so sometimes that can run into more complex scenarios with rate limiting so that for sure comes up the other thing is it's harder to monitor so there's a lot of monitoring solutions for REST API s and with graph QL there's only one endpoint you always hit the slash graph QL and point for all your requests and so splitting things up by all right this resolver took this long to request the data this query took this long and also because the nesting in graph QL there's this resolver then there's this resolver and this has a resolver everything is a resolver and it's all nested so it's one complex to monitor the performance of it you can use Apollo engine and I did try that for a little bit but if you don't want to use Apollo engine and send your data to Apollo there's not a lot of other great options or open source options Apollo tracing I tried out as well as another one but I found like it just killed performance because it was basically tracing every single field and if your data was getting if you returned a lot of data from a resolver Apollo tracing just slowed things down too much but that's just kind of side note if you know some of the tools in graph QL didn't really work out when I tried monitoring it so I ended up doing kind of like my own little solution for that that's something you'll notice with graph QL is not all the best practices I would say are out yet and they're still being established so it's definitely something we're gonna have to explore some of this stuff on your own and kind of figure it out then the last thing I would say is there's not really a ruby on rails or Django quite yet where basically it is a full framework where it is helping you out and helping you be building all these things out these tools are trying to get closer to it they're not quite there yet but there's just not this level of these if you're familiar with these web frameworks and the stuff they would handle for you there's just not this level of helping out yet so I would say those are the things I felt as disadvantages when I was using graph QL and I think it may be possible to build out some of this tooling for when you're using REST API and maybe this tooling already exists and I don't know about it but I kind of want to use like a Apollo version for REST API I think they may even have one if I remember but yeah those are kind of the things that I thought were great about graph QL and not so great about graph QL so in general I would say I felt like graph QL helped me out a lot on the front end be productive on the front end but also took more time to do some of the stuff on the back end so that's something to keep in mind if you're not as proficient in the back end either consider using one of these tools to help you out or maybe consider not using graph QL but as a front-end developer the experience using graph QL is very nice and so I like that a lot so if possible I think it's really nice to use graph QL for the for your front-end developers they will really enjoy it but there you go that is the pros and cons of graph QL versus rest

Channel: Ben Awad

Views: 69,645

Rating: 4.9424777 out of 5

Keywords: graphql, rest, GraphQL vs REST, Side Projects, graphql side projects, GraphQL for Side Projects

Id: AYZOHt6kz6Y

Length: 14min 15sec (855 seconds)

Published: Thu Aug 22 2019