Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST vs. GraphQL – A search for evidence on which is better

42papers.com

Post reply on HN
Print view View original

21–30 of 243 posts

Re: REST vs. GraphQL – A search for evidence on which is better

#21

Post by TheCoelacanth »

zanellato19 wrote: post #14
emilecantin wrote: post #10

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. 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. Writing a backend becomes more about describing what data is available, on what terms,…

I have the opposite experience working on the backend. GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored. Its much harder to make an efficient resolver than it is making an efficient REST endpoint. Errors are harder, because HTTP codes are not used and monitoring is a lot more complicated. I see value in GraphQL - but I think it brings a lot of cost to th…

In my experience, N+1 queries are roughly as easy to run into with naive GraphQL as with naive REST. When you are optimizing the queries, it's slightly easier to get rid of the N+1 behavior in GraphQL than in REST because you can see exactly what data the client is trying to get and can fetch data differently based on that instead of needing to come up with your own way for the API to describe what data to fetch.

Re: REST vs. GraphQL – A search for evidence on which is better

#22

Post by djlewald »

recursivedoubts wrote: post #19

The results are intuitive and in favor of GraphQL, especially as query complexity increases. GraphQL makes loads of sense for modern javascript thick clients: The front end developer is going to want the same thing that a back end developer has: an expressive, general query language. 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 & applica…

I am a fan of GraphQL, but what evidence do you have for "REST sans a hypertext was always a mistake"?

Re: REST vs. GraphQL – A search for evidence on which is better

#23

Post by dudul »

gabereiser wrote: post #18
zanellato19 wrote: post #14

Earlier quoted context omitted.

I have the opposite experience working on the backend. GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored. Its much harder to make an efficient resolver than it is making an efficient REST endpoint. Errors are harder, because HTTP codes are not used and monitoring is a lot more complicated. I see value in GraphQL - but I think it brings a lot of cost to th…

Can you give some concrete examples on the N+1 problem? I’ve heard this before but never experienced it.

a query that lets you fetch a list of posts, each post has an author field. So if you ask for these, a naive backend will "resolve" the author for each post individually (so N queries to the DB to fetch 1 author each time) as opposed to a single resolution for the batch of authors.

Re: REST vs. GraphQL – A search for evidence on which is better

#24

Post by treis »

rhacker wrote: post #2

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 m…

There's no law against putting joined data into a REST endpoint. As an example, I had to consume an API for a customer's subscriptions. They did it by the book where Customer has Subscriptions which has Items which has Prices. That was a huge performance issue for us because it was 4 round trips. But they didn't need to use GraphQL. They just needed a fullDetails end point for subscriptions.

Re: REST vs. GraphQL – A search for evidence on which is better

#25

Post by zwily »

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.

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.

Re: REST vs. GraphQL – A search for evidence on which is better

#26

Post by tynorf »

gabereiser wrote: post #18
zanellato19 wrote: post #14

Earlier quoted context omitted.

I have the opposite experience working on the backend. GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored. Its much harder to make an efficient resolver than it is making an efficient REST endpoint. Errors are harder, because HTTP codes are not used and monitoring is a lot more complicated. I see value in GraphQL - but I think it brings a lot of cost to th…

Can you give some concrete examples on the N+1 problem? I’ve heard this before but never experienced it.

I think the classic example is article list with author details. You load the articles (one query), then for each article you load its author (N queries). Naive use of an ORM causes this:

  articles = Article.load(limit=10)
  for article in articles:
    # .author implicitly runs a query
    author_name = article.author.name
This can be avoided in ORMs providing prefetching (e.g. `Article.load(eager_load='author')`).

Re: REST vs. GraphQL – A search for evidence on which is better

#27

Post by recursivedoubts »

djlewald wrote: post #22
recursivedoubts wrote: post #19

The results are intuitive and in favor of GraphQL, especially as query complexity increases. GraphQL makes loads of sense for modern javascript thick clients: The front end developer is going to want the same thing that a back end developer has: an expressive, general query language. 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 & applica…

I am a fan of GraphQL, but what evidence do you have for "REST sans a hypertext was always a mistake"?

REST requires a uniform interface. Hypertext (or media) is that uniform interface. JSON isn't a hypertext.

Therefore JSON isn't an appropriate transport for a REST-ful API.

I understand that 99% of the internet disagrees with me.

Re: REST vs. GraphQL – A search for evidence on which is better

#29

Post by treve »

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.

This paper takes a typical query, and just overlays it on a CRUD-style REST endpoint, but it ignores:

* REST can definitely be strongly typed. There's OpenAPI, and JSON-Schema. In many instances I think this will work better than GraphQL, as the data you get back is more likely to follow a fixed format.

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

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

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.

Re: REST vs. GraphQL – A search for evidence on which is better

#30

Post by baumandm »

gabereiser wrote: post #18
zanellato19 wrote: post #14

Earlier quoted context omitted.

I have the opposite experience working on the backend. GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored. Its much harder to make an efficient resolver than it is making an efficient REST endpoint. Errors are harder, because HTTP codes are not used and monitoring is a lot more complicated. I see value in GraphQL - but I think it brings a lot of cost to th…

Can you give some concrete examples on the N+1 problem? I’ve heard this before but never experienced it.

Imagine you're working on a bespoke blog engine for your company, so you have a GraphQL API that lets you query for all articles or just a single article.

Now the product folks want to add comments, so you add a new comments field on your article, with a new field resolver that queries the database for comments like SELECT * FROM comments WHERE article_id = ?.

This works great when viewing a single article: the frontend makes a single query to the GraphQL API, which makes 2 database queries: one for the article details and one for the comments

But then the product folks want to update the article search page with a expandable comment section for each article, so you can preview the comments for an article. Easy enough, all you have to do is add the comment field to the GraphQL query for the article search page, it's a GraphQL success story!

But now when the article search page loads, it runs 1 GraphQL query that retrieves 20 articles, and for each one it runs the SQL query to load comments. So instead of making 2 database queries it's 21.

Now we have performance scaling along with the number of results on the page, which is not ideal.

Post reply on HN