I think this paper misses the point. If you're a front-end developer, if you have a robust graphql endpoint available to you it's unbelievably amazing and productive.<p>But providing a robust graphql endpoint that is performant, scalable, secure, etc, is much more difficult than REST. GraphQL is optimizing for a different set of developers, and this paper only studied one group.
I'll be honest. I hate GraphQL. It probably makes sense in a world where everyone uses graphQL, but to me it felt like having to learn yet another query language to do what to me seems straightforward using a simple REST api.<p>I may also be old and cranky and you should probably get off of my lawn.
This paper has a pretty naive understanding of REST. While 'REST' can mean something different depending on who you talk to, I think in the context of a paper we can expect a bit more research.<p>This paper takes a typical query, and just overlays it on a CRUD-style REST endpoint, but it ignores:<p>* REST can definitely be strongly typed. There's OpenAPI, and JSON-Schema. In many instances I think this will work <i>better</i> than GraphQL, as the data you get back is more likely to follow a fixed format.<p>* Mutations. In GraphQL this is an RPC-style feature, whereas with the typical 'REST as CRUD' API you write in the same format you read, which can make this a lot simpler.<p>* Discovery. The paper discusses that REST can benefit from an 'IDE', but if you do REST well your browser is your IDE and you serve text/html as well as JSON. Ignoring good hypermedia APIs that serve multiple formats, there's also systems that let you test APIs based on for example OpenAPI schemas.<p>To me this is not a comparison between REST and GraphQL, but a comparison between GraphQL and a GET request on a poorly documented, low effort HTTP endpoint. To be fair, many APIs are just that.
As someone who's worked with both approaches, at all levels of the stack (both backend and frontend), I think the paper (at least, its abstract) is missing the point.<p>While I do "feel" faster when working with GraphQL, I think the main benefit is that it abstracts away the busywork of transferring data between frontend and backend.<p>Writing a backend becomes more about describing what data is available, on what terms, how it fits together, and the operations you can do on it (mutations). Gone is the busywork of writing routes, handling CRUD in a zillion slightly different ways, etc.<p>On the frontend, Apollo-client lets me just write my app, not having to handle data-fetching, loading & caching for the zillionth time. I need an additional field? Just add it to the query! No need to get everyone involved.<p>Of course, there are traps you can easily fall into with Apollo's caching, N+1 queries on the backend, etc. But in my experience, while you do have to "drop down a level" sometimes to fix these, you spend most of your time at the "higher level".
As someone who has heavily used both REST and GraphQL in the past and actively, I find this comparison heavily similar to using raw HTML versus React. When it really boils down, GraphQL is just REST with types and the capability of performing multiple requests in one. Much like React is a way of creating component types from HTML elements.
GraphQL takes a bit more work to get setup and running, but it's soo worth it in the end if you value typing. One of the most impressive parts of GQL that REST isn't capable of having, is the vast tooling ecosystem enabled by a standardly typed data transfer model, the fact that anyone can write a library that can automatically hook into your model is incredibly powerful.<p>I find most people who have negative opinions on GraphQL simply haven't taken the dive yet to fully understand it, and they typically overthink what it actually does. In my opinion, if you're writing a progressive web/mobile app with relational data, you should hands down be using GraphQL.
Does this actually pass as an academic study? It is presented in the format of a study (it looks like one) but to suggest GraphQL is better than REST based on the expenditure of effort for building out the first iteration of code for cherry picked scenarios is a first-year undergraduate CS101 study at best. Also, who funded this study?<p>I want to know the actual costs of GraphQL. What are the tradeoffs with REST? What are the limitations? We're not going to hear from managers who are damage controlling their decisions, but maybe the developers paying for GraphQL adoption wouldn't mind sharing grievances? Now that money and reputations are at stake, I think that unfortunately it will be a while before the tech community starts admitting to mistakes, just as was done with adopting ORMs.<p>The typical pitch about GraphQL is that it is intended to alleviate the pain of updating ORM dsl every time a change to an endpoint needs to be made to satisfy frontend requirements. Aren't updates to the GraphQL DSL replacing those made to the ORM? The problem hasn't been eliminated but replaced. One problem was replaced by another problem.<p>If the worst part about working with a REST api with raw sql calls is that you have to make a few straightforward changes, while maintaining complete control of your sql, you're doing great.
GraphQL specifies schema and documentation, and implementations usually come with introspection tools, which is not the case for REST. It would be more fair to compare GraphQL to something like Swagger.<p>That said, GraphQL libraries and tooling tend to be less fragmented and more ready to use than for equivalent REST stacks, which makes development much easier. A simple API built in Python with Graphene looks terse and declarative, while doing the same with Django REST Framework requires adding pages of plumbing code to build an equivalent REST API.<p>Re: GraphQL being a pain for a backend development - I don't quite understand that argument. If you want to keep a tighter control over the schema, you can have it - the API schema does not need to be a reflection of the underlying data schema with all its relationships - it should be the front-end developer's job to convince you that this or that complex relationship needs to be exposed via GraphQL and let you make sure that it's served efficiently.
This is a flawed comparison. GraphQL is probably a superior query language. The more salient question is how the complexity of back-end API endpoint implementation differs.<p>The answer is that it varies widely between ecosystems (i.e. you are going to have a totally different experience developing a GraphQL endpoint in PostGraphile, Graphene, and Apollo)...and the paper doesn't mention which back-end technology was used.
I read this article about GraphQL vs REST a while ago, and found it quite interesting.<p><a href="https://www.graphiti.dev/guides/why" rel="nofollow">https://www.graphiti.dev/guides/why</a><p>The author is arguing that by borrowing a few ideas from GraphQL, a “modern” REST API gets the benefits of both.
The results are intuitive and in favor of GraphQL, especially as query complexity increases. GraphQL makes loads of sense for modern javascript thick clients:<p>The front end developer is going to want the same thing that a back end developer has: an expressive, general query language.<p>And the API developer should want to give it to them so they aren't dragging their API around all over the place as fiddly UI & application logic changes are made[1].<p>I'm glad to see javascript client-server apps heading this direction, and leaving REST/HATEOAS to hypertext-oriented approaches[2].<p>REST sans a hypertext was always a mistake.<p>[1] - <a href="https://www.infoq.com/articles/no-more-mvc-frameworks/" rel="nofollow">https://www.infoq.com/articles/no-more-mvc-frameworks/</a><p>[2] - <a href="https://htmx.org" rel="nofollow">https://htmx.org</a>
The site 42papers.com that serving this link is build with Super Graph a GraphQL to SQL compiler. Tech like this makes GraphQL clearly the easier, faster and better option. I built Super Graph since I wanted something better than REST while building apps and did not want to go down the rabbit hole of GraphQL frameworks where I would still need to write and maintain all the database query code for the app.<p>I started out not liking GraphQL cause it didn't really reduce the code I needed to write but on digging deeper it seemed to be the best way to represent a data query from an app now only if something could convert that into SQL automagically. This was the motivation for Super Graph.<p><a href="https://github.com/dosco/super-graph" rel="nofollow">https://github.com/dosco/super-graph</a>
Admittedly I skimmed -- observed that the paper dove really deep into time to perform queries and implement desired behavior, but didn't spend much time on implementation of GraphQL vs a REST API.<p>One statement made that stood out to me:<p>> it is clear that
the availability of a type system—expressed as a schema—
is one of the key benefits provided by GraphQL<p>So I wonder what the results would look like if you had an OAS spec file for the API you were hitting (with autocomplete in VSCode), seems to me that's the best of both worlds: ease of implementation on the server side, ease of use on the client side.<p>This to me feels like an argument of better tooling and (self) documentation rather than one technique over another.
Yes, had this discussion on here before. While in REST you can more or less optimize a service to be performant at what it does, the moment there is another service that you need to fetch some additional data, the browser would be required to orchestrate that, which means you're also waiting for the return trip on the first call before you can even get the secondary data. This alone makes REST far less favorable in my opinion.<p>The secondary is that operations are standardized in GQL. Whereas in REST I can pass data in through:<p>Query params<p>Body<p>Headers<p>Path variables<p>Each team will do this differently. In graphQL these inputs are pretty much standardized and you have the option to implement security through headers. This makes GQL decoupl-able from HTTP (at some point). That's a great incentive too by itself since at some point the web may just be media distributions + services. Where media distributions is just HTML/CSS/JS/etc... There's new reasons as time moves forward media distributions needs to take place over HTTP.<p>The top response to this is caching - in other words every device on the planet knows HTTP so caching in GQL becomes a secondary thought. So yeah there's that. GQL has some variously applied caching semantics - so YMMV but personally I still feel like the gains from the first point are so dramatic that most people won't really care about this.
I always think about GraphQL as pushing versioning into the future when it's either:<p>1) the product is dead<p>2) original folks moved on<p>3) "it's no longer my problem"<p>The if-then-else spaghetti code it creates on the back-end whenever an API breaking change is needed is always cute.
Out of all the API implementations I've created in my career I've had the most success implementing BFF (Backends for Frontends) with simple RPC'ish endpoints. Everything else never quite fit right and wasted so many hours.<p><a href="https://samnewman.io/patterns/architectural/bff/" rel="nofollow">https://samnewman.io/patterns/architectural/bff/</a>
GraphQL has two notable advantages, neither of which are measured here. First by allowing the client to specify precisely what to retrieve the backend isn't catering to a specific client. This allows for decoupling so each team can develop quicker and with fewer changes down the road.<p>Of course REST can also be decoupled only needing to follow conventions and defining the resource formats. What it doesn't provide is the second benefit of GraphQL which is eliminating round trips for accessing related resources. This is sometimes done by creating an intermediate 'BFF' service on the back end to serve requests as the client would like them but now that's sensitive to both client and REST API changes.<p>In short, it's not about the development speed of the first client/server. If that were the case use gRPC etc, generate the interface, implement and you're done. It's about the supporting ongoing changes. Perhaps gRPC or similar will become prevalent enough to replace both REST and GraphQL.
GraphQL vs. REST somewhat resembles SQL vs. (document-oriented) NoSQL. If you can agree with your clients on certain access patterns (queries), you can design your RESTful API and your database collections, respectively, to suit these.
If clients want full flexibility in what they query and avoid over-/underfetching, GraphQL and SQL (databases) might be better.
I have never implemented GraphQL, so I can't speak from experience, there, but it does look pretty cool (if a bit "heavy").<p>I have implemented REST. I don't like "pure" REST, where POST, PATCH, and PUT statements are submitted as XML and/or JSON.<p>I tend to do what I term "REST-like," sort of the way most APIs seem to do, these days, where the sending methods are done similar to standard URI GET/POST stuff (URI arguments).<p>I tend to have responses come back as both JSON and XML, with a translator between them. XML is useful, because I can publish a schema, but otherwise, I prefer JSON.<p>But REST-like is quite simple. I don't need to bring in any dependencies to provide the API, so it's fast and lightweight.<p>But then, I have fairly humble servers. I suspect that GraphQL would be something I'd want for more ambitious servers.
Think about an API like a control panel for a machine. It is precisely designed for an operator abstracting away the details of the machine's electrical schematic and every component. It is <i>user focused</i>. GraphQL is like opening up the entire machine, stripping off the panels and working on live circuits.<p>IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're making a case for how awesome GraphQL is, I think perhaps your REST API design needs to be properly thought out. I personally like to start with GraphQL, once everything is ready and I know what I want, write proper API endpoints. They can be REST-ful or REST-less. One API call for one function the front-end needs to perform.<p>If the wiring in the machine changes and need fancy brushless motors are added, the operator doesn't need to worry about it. They can always replace the control panel with a new v2 version if they want additional features, but we guarantee that v1 version will continue to function. This is beautiful design.<p>APIs don't have to be REST-ful and they should not be some kind of an analog of the backend database schema. API - it is in the name, "Interface".
My problem with graphql always comes down to permissions and performance.<p>I feel like we went through the thought process of: okay, front ends are smart enough to ask for the data that they want, so why not just let them structure their own queries? But my problem is, the only time a client is smart and and to just ask for whatever they want us if I'm building an admin application, otherwise, all sorts of access control needs to be added to various levels of most queries, something I've never felt as though GraphQL handles well.<p>Then there's the performance stuff, hitting caches or doing joins, it's much harder to make a GraphQL backend know when it can do these things, short of simple cache lookups by very limited keys.<p>With REST, I'm somewhere in the middle. I'm saying, okay, these are the resources, and these are the actions. You might get a little more or a little less data than you wanted with your response, but I know exactly what you're getting, can optimize it, and test the shit out of it.<p>I'm by no means resistant to new technology, I have just never worked on a project that avoided these pitfalls.
The two are not exclusionary. For me it is like having a higher abstraction API that provides for 80% of client developer needs, and a 'closer to the metal' API that provides for the remaining 20%. REST gives the popular/frequent queries optimized and canned, while GraphQL gives the power to create completely custom adhoc queries as needed.<p>If you are creating a data service then I think you really need to have both. Which you do, and how much of it, is more likely to be dictated by time and budget. Many will need to figure out who their 80% audience is and prioritize based on that.<p>Still a few REST services can be done, then GraphQL added with not mutators, then add mutators and more queryable data, etc. Start with the bare bones, just like you would a startup MVP and grow organically from there.
A while ago I decided to build another one of those Hacker News clone, and decided to use GraphQL, everything was fine, until I got at the comments...<p>You cannot ask for all the children of a main comment or a thread, something like "give me all the comments and sub comments of thread X" is impossible, I was quite shocked because I read nowhere about this limitation, I solved it adding an extra field to my response adding a "father" field, so I needed to organize and sort the data at the front-end, instead of using an already sorted JSON like would be possible with rest.<p>With all due respect, I find that most of GraphQL tests and examples return mostly simple data that is kinda easy anyways.
Am I missing something, or was this only about implementing queries with a fixed backend?<p>What's the numbers on implementing these? In different languages other than javascript? Last time I looked, implementing graphQL with django was pretty janky and limited.
Serious question: given how difficult correctly parsing SELECT commands (and avoiding SQLi and other horrible issues like db parser impl bugs) is, why hasn't someone implemented a db whose query language <i>is</i> graphQL?
GraphQL is great to iterate with once you have built up the schema. However, after some time your queries will stop evolving and at that point you are better off with a REST API for the security and performance benefits.
The real cost of GraphQL is resource usage/performance on the backend.<p>On the development side, the cost is that GraphQL allows developers to get away with writing really messy code whereas REST basically forces them to follow a more structured approach with better separation of concerns between components (to mirror the separation of concerns which REST endpoints naturally have). But I don't think this concern is that important because developers CAN design good software with either approach if they have the right mindset.
I think one problem of gql relates to caching.<p>Using rest, it's dead easy to enable caching on load balancer or CDN level with background updates.<p>But with graphql- it's not so trivial. Youll have to do workarounds by caching POST requests (which imo is bad practice) or use GET requests, which might not work because the URL gets too long.<p>Or use named queries, but then - what did you gain compared to rest?<p>Another problem is that you expose internals and may more easily make yourself vulnerable to overload attacks.<p>My two ören
On my servers I do away with either. Instead client submits JSON object and gets JSON answer. Simple HTTP based RPC. But my servers of course are not some generic storage of knowledge for mining. Instead they're doing some particular processing and administration. So clients are not given as much freedom as in GraphQL. And I am free from headache of implementing some generic backend query service for no benefit.
There is some kind of toast on this site that never goes away telling me all kinds of info I care nothing about (new member, so and so bookmarked this etc). I would like to fallaciously suggest that only a site with such poor judgement would host papers such as this that come to such erroneous conclusions
Won't graphql shift a lot of the logic to the frontend?<p>Personally I don't like having businesses logic in the frontend (though I have had "discussions" with other devs who believe it is not problem to have logic scattered about your app).
Read a lot about how Relay is better than GraphQL Apollo client, but haven't got much info on the adoption of Relay vs Apollo client and Relay is too complicated. Now this has added to more GraphQL vs Rest complexity.
Generalizing integrations obfuscates business models, creating complexity.<p>Both REST and GraphQL are convenient in the short term, but will hide important interactions over time.
REST without a IDL language with a schema definition is < GraphQL<p>But things like OpenAPI =< GraphQL<p>GraphQL has some disadvantages thought, due to the graph setup.
This is comically meaningless as far as evidence for making a decision goes. It reminds me of the various garbage studies purporting to show that functional programming leads to lower defect rates.
In my experience it's a lot easier to write performant, scaleable, and secure GraphQL API's than REST API's.<p>Rest is a constant struggle between complexity, functionality and authorisation.<p>The more flexible a REST API becomes, the more it becomes like GraphQL minus the standardisation.<p>I wrote a blog [1] on writing GraphQL API's in TypeScript. It focuses particularly on authorisation and relations.<p>[1] <a href="https://dev.to/nickkelly314/writing-a-graphql-typescript-server-in-nodejs-1n7e" rel="nofollow">https://dev.to/nickkelly314/writing-a-graphql-typescript-ser...</a>