REST has been preferred by many developers to send data over HTTP because they didn't need to install additional software or libraries when creatin...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I think the title is wrong, it should be more like "difference b/w graphql and rest". You can't just say to stop using one over the other. Both have their own benefits.
Also, the content of this post is more like telling the difference.
My point here was to show how Graphql can make your work more easier. I also said that Graphql is not always the best solution.
The title of your article is literally, "4 reasons why you should use GraphQL over REST APIs" and your slug is, "stop-using-rest-for-apis-53n".
Also, GraphQL has many drawbacks, none of which you really mentioned. What about the N + 1 problem? Or having to use and/or implement DataLoader?
In the middle of the post I said that it is difficult to implement caching and that it's not always the best solution.
he changed it now :).
His article, his rules. He wants the title to be like that, let him name the article like that.
GraphQL is all cool and dandy until you have files to send over. I am aware that you can send it via blob, but who does store images as blobs in database??? I also held discussions about converting blobs on the backend or sending them over to the third parties that can handle it and store it as a file with url of the image in response. Took significant amount of time to process it all and that was just bad UX. Remember - your users are using your app and they don't really care what's under the hood.
REST API over fetching and under fetching can be resolved on the REST API, I am sure that you do it yourself if you are fullstack so you have control what is sent over which API route or if you are frontend, I know it is difficult, but please try to communicate with, you know, backend guy who handles the REST API routes. It's not so hard.
I have used both, both have their use cases. GraphQL for Jamstack sites is great, for much writing to the DB and especially for files handling I don't find it so attractive.
just my 2c
Sending blob is not strange . you can do it also in REST, and inside backend you can convert it into file, store the name in database and file in your storage
You can add Content-Type to the response in REST, put the path directly to "src" attribute to your img.
If your API is under or over fetching: You wrote a poor API method. It's not about REST vs New ShINy TeKS.
And where I haven't used GraphQL, I have used something with a similar concept ( OData) and everything about the concept to me, is weird and wrong.
The logic behind over fetching is that you can't specify which resources you want in REST, you get result and then filter it to get what you want.
If you need to filter data, you might be missing a route (for example getting a specific thing with
/api/things/:id).You can also use path argument to filter out things (with
/api/things?group_id=23) or even stick those arguments in the request's body.I would say GraphQL has way more disadvantages over REST.
The inability to cache results (or if you manage to do so with forward caching proxy with lots of RAM and added latency) makes this only solution for systems that need no performance or scaling. Systems with hundreds, thousands or more clients or requests/second will suffer greatly and trash your cache by storing non-reusable GraphQL results.
GraphQL will more likely result in poor database performance as there is no way to optimize for all combinations of all database columns by indexes. Either you create wide tables (by de-normalizing them) covering every possible column combination by an index causing heavy disk usage and your database INSERTs to take seconds instead of milliseconds or you normalize your database and cause tens or hundreds of JOIN operations. In either case there's no optimization possible with GraphQL as the model is created at the front-end without back-end developer interaction and his/her possibility to optimze for performance.
Since support for HTTP Push in HTTP/2 and HTTP/3 is now killed in the RFC draft your options for size and performance optimized REST calls are basically
sparse fieldsetsor for better cacheabilitypartials.Just to chip in on caching, caching seems to work here over at Spotify and we get a decent amount of requests/second. It's not perfect though and i's not straightforward but you can get somewhere with query hashing for instance.
Out of curiosity, how much dedicated cache storage your typical GraphQL cache server has?
hmnn im not sure, i think caching is mainly handled through its subsidiaries, so cant say to be sure. Bigger issue seems to be fanning out for requests, as one graphql request can potentially mean a lot of subsequent requests fanning out over multiple microservices.
Statistically as tiny as 5 column table (with 4 really usable columns as one of them is typically an identifier) has 120 (5 factorial) different ways to order columns in GraphQL query that produces 120 different cacheable queries with identical result that would in normal case be cached and reused but now is trashing your cache. This becomes more prominent in bigger team where everyone writes their own queries.
thats very academic, but just don't do that then. i haven't seen an impact yet on our side, but what you are saying is probably true, sounds like the caching approach should be different, e.g. order on the fly. not saying its not a problem, i'm just saying were not having that problem, yet.
Or actually thinking about it, sounds like maybe caching in the wrong place, just cache the most used case and then sort on all the results? Otherwise i guess yeah you would need to cache for all those cases, taking up space.
I have seen these "REST vs. GraphQL" articles lately a lot and was thinking that it might not be that black and white. I believe that both concepts have their benefits and can work quite well together. Why not using a 2-tier architecture where REST is used for the internal systems (e.g. a back-office application that doesn't need that much speed) and GraphQL is used for the customer-centered apps? The caching ability of REST might be useful if you for example have a slow running legacy service. You could request parts of the GraphQL query via REST and get the cached result instead of waiting for the legacy service.
tl;tr: I believe both play well together and would love to see more articles about how to use them useful together.
will make more about it soon.
Thanks for the article.
I just wanted to mention that a lot of your benefits are based on implementation details in regard to specifically GraphQL. Over and under fetching is and can be an issue with GraphQL too, especially when it sits between the client and microservices. I don't really get your object definition point, i also think that might be an implementation detail you don't have to do. Could you expand on this? Caching can again be an implementation detail, REST can also fail to cache.
I think you are looking maybe too much from an implementation effort, i'm wondering what your thoughts are based on it from an solution oriented point of view? For instance the fact that GraphQL could be a good fit for many clients, or around versioning? I would love to hear your thoughts
Here are some use cases of GraphQL:
-Apps for devices such as mobile phones, smartwatches, and IoT devices, where bandwidth usage matters.
-Applications where nested data needs to be fetched in a single call.
-A composite pattern, where an application retrieves data from multiple, different storage APIs.
The last two bullets, why would you not do it with REST? Especially the last one im wondering what the benefit is of choosing GraphQL? Is it convience, because the data loaders are already there?
On the second last bullet about nested calls we can suppose that we blog or social networking platform where posts need to be fetched along with nested comments and details about the person commenting. You can also refer to the example provided in the article.
On the last bullet point we can suppose that we have a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, and third-party analytics tools to capture end-user interactions.
Hope this answers your question.
Not really sorry, the first can be done as well with REST, if you would include all that info in the request for the post right? or is that not very RESTy? The last bullet i also still don't completely understand. A backend using rest could still easily consolidate those services?
GraphQL allows multiple resource requests in a single query call, which saves time and bandwidth by reducing the number of network round trips to the server. It also helps to prevent waterfall network requests, where you need to resolve dependent resources on previous requests. For example, consider a blog’s homepage where you need to display multiple widgets, such as recent posts, the most popular posts, categories, and featured posts. With REST architecture, displaying these would take at least five requests, while a similar scenario using GraphQL requires just a single GraphQL request.
If you put all of the requests in one
APIthen you'll to write many lines of code compared toGraphQLand it'll increase execution time. The goal here is to make thingssimple and fast.Nice 😄, I have heard
GraphQlhas many good features compared toREST.Post Title can mislead beginners to completely stop using
RESTwhich is not what you mean i know. By the way title example like , UseGraphQlto create modern APIs, may be good, Just a suggestion:)Finally its not between
RESTorGraphQlAlways use best tool for the Job.Good suggestion.
Hell no. Having used both graphql and rest apis, graphql is NOT a silver bullet. It has many downsides (harder to debug from the browser, terrible error handling, more complicated to build security rules around certain days points, etc), and only one big advantage: neer infinite customizability of requests by the client code.
If you are making a public API with a wide range of consumers and possible use cases, graphql is a good choice to consider. If you're creating an API that's only being used by your apps, or has limited use cases, stick with traditional REST. They are different tools for different jobs.
yes, that's why I mentioned use cases for Graphql and said that Graphql is not always the best solution.
I like the idea of GraphQL. I find building resolvers properly with good caching is something that most people don't do (causing worse performance).
It also encourages building a monolith. With RESTful APIs it is easier to deploy smaller services or microservices.
Now, you can use federation or just really lean on your developers to not reach into other services. What I mean by this, say you have a e-commerce site. With RESTful you might have APIs that cover Account, Cart, and Payment. The cart API might call the Payment and Account APIs. I keep seeing GraphQL developers just reaching into the other domain's code. The cart calls the code from Account and Payment (or worse, reaches directly into the database).
I realize this really isn't a fault with GraphQL itself, but more around development patterns. Still, almost every tutorial is teaching developers to build tightly coupled monoliths that at enterprise scale is not a great pattern.
This is good and I like it so much. I am a high fun of GraphQL with the way that you have a single endpoint is also a property I like. However, GraphQL has yet several accounts to improve before deciding that it is better than Rest. File Handling has been a headache for most of developers in GraphQL. Rest has its good and works better when you are working on big projects. While GraphQL would need to be preferred when related data is needed and not such a big application.
You’re right. Graphql is improving as years go by and I think for now someone can use them together as one is good at one thing than the other.
Thats a good article about difference between GarphQL and REST yes, but it is more of a clickbait title, just like Siddhant said. You adress one problem of REST, wich can happen only if you cannot make changes to the API, wich you solve by creating doing the said changes on GraphQL? this use case doesn't make sense for me. Yes GraphQL can be nice for some case, just like some poeple like using NoSQL DataBase, but with bigger scenarios, it becomes way harder and less time efficient to rely on different solutions (Solutions that keep being improved with time and will get replaced one day indeed, but it's never White or Black, some things are better suited for different problem, thats all)
yes, that's why I mentioned use cases for Graphql and said that Graphql is not always the best solution.
No offense but this title alone just kind of makes it seem like you don't have much of an understanding of the topic either. GraphQL is a lot different than REST APIs, you can't use GraphQL "for" REST APIs.
What are the disadvantages of graphql? (Nested level count maybe?)
It has some limitations. One of them is that implementing
cachingis complicated compared toREST.👍
If you have a system with resource policies. Like say level 1 customer support can only see customers numbers, account balances, but not individual orders, PII or inventory levels.
You'll have another kind of fan out complexity since you can just reach across the whole graph, you need to propagate policy decisions in some maintainable manner when the queries aren't just localised to just say the accounts balance endpoint itself.
GraphQL API migrations like renaming fields and restructuring is also left as an exercise to the reader. The answer commonly thrown around is "but you shouldn't", which of course you'll need to eventually have breaking changes it just avoids some struggles of RESTful API's.
All solvable problems obviously, but if you don't already have good answers, but do have a complex domain to deal with I wouldn't try until I understand exactly what I should do.
I love graphQL, not using it now, but I can't wait to use it again.
What I'm trying to say is that it has its downfalls.
Thank you for your article i have changed my mind about GraphQL
Glad it helped.
This is not true: "REST causes over-fetching or under-fetching".
"In REST you can define the request object on the Backend and in GraphQL you define the object on the Frontend." - what means that ?
Edit:
The heading must be "why you should not use".
Don't use something, just because it is a hype.
The advantages of GraphQL are the same and for REST .
The disadvantages of REST are the same and for GraphQL
It is just a POST request to the same URL, nothing fancy.
May be, the packages for GraphQL are advantage like state management, but you can use the most popular of them with REST API, too.
Nice title change, now the article is perfect 😊!
Haha, thanks 😀.
yeah, sometimes it's not appropriate to use GraphQl for small tasks as for REST works well on small tasks.
You make a versus but not clear. Anyway i will search GraphQL. Thanks
Hy all,
You can also look at the grpc protocol
Regards