REST vs. GraphQL – A search for evidence on which is better • Hacker News Board

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

#141

Post by mumblemumble » Wed, Dec 16, 2020, 3:42 AM UTC

cogman10 wrote: post #102

mumblemumble wrote: post #86

Earlier quoted context omitted.

Keeping database load under control, for example. With an API that keeps tighter control over access patterns, you've got a more predictable target for optimizing your indexing strategy. With GraphQL, you've got to worry about the possibility that some client figures out how to craft a query that slips between all your indexes and causes the database engine to resort to doing things the hard way. So, worrying about t…

The trick is to abstract away what can make the DB tip over. This complicates your servers, for sure, but pays dividends on performance/scale. How do you do that? https://github.com/graphql/dataloader However, to be super efficient you need to give up on some consistency. You simply can't have data points which join directly in the db. Instead, you need to make separate parallel requests for those datapoints and let…

Sure, but that's a great example of what I'm getting at. All that complexity may let you do some pretty cool things. But it also comes at a cost, in terms of both development effort and implementation complexity, and I certainly wouldn't call it easy.

I fear, sometimes, that our collective tendency to prefer talking about the most interesting or most capable technologies tends to bias us toward over-engineering. Slinging JSON over HTTP is, in my personal opinion, a pretty hokey hack. But it's also the option that's the easiest to implement, the most widely understood, and, more often than not, it's more than up to the task.

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

#142

Post by fastball » Wed, Dec 16, 2020, 3:48 AM UTC

valenterry wrote: post #97

baumandm wrote: post #30

Earlier quoted context omitted.

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

This problem exists in REST APIs in the exact same way though, unless you specifically optimize for this way of querying. But then you can do the same thing with GraphQL, so in the end GraphQL is not worse off, actually rather better because at least the problem exists only between backend and database, not between frontend and backend and database.

The idea is that there is a sort of contract between the backend and the frontend.

If I conscientiously create an API endpoint that allows you to fetch articles with their comments, I'm gonna craft that query to avoid the N+1 problem. So when someone uses it, perf isn't scaling linearly.

With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything. They say "yay it works, GraphQL is amazing", and nobody realizes this is causing scaling problems because nobody on backend actually thought about it.

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

#143

Post by valenterry » Wed, Dec 16, 2020, 3:52 AM UTC

dyeje wrote: post #132

valenterry wrote: post #125

Earlier quoted context omitted.

Why would your routes with REST magically be specific and your queries with GraphQL not?

REST endpoints typically return a specific set of data that you can optimize queries for. Whereas the GraphQL endpoint must handle arbitrary queries which will require some logic to prevent N+1 queries on the related tables or even resolve to other data sources.

> REST endpoints typically return a specific set of data that you can optimize queries for

You mean when someone creates a REST API he magically knows in advance how it will be used and writes a bunch of specific, optimized endpoints and queries such as "/magic-endpoint/" which returns 20 blogposts with their comments?

I don't think so. And even if that were true, the same could easily be done with GraphQL.

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

#144

Post by t-writescode » Wed, Dec 16, 2020, 3:55 AM UTC

cratermoon wrote: post #59

ar_lan wrote: post #53

Earlier quoted context omitted.

It doesn't lose it - it just doesn't remain an advantage over the alternative. It's not like if there is a schema with a REST API, the GraphQL alternative becomes un-typed.

What's the difference between "losing it" and "it doesn't remain"? I didn't say GraphQL lost the feature, I said it lost the advantage. I see also the paper says, in bold, "it is unfair to attribute the gains observed with GraphQL only to the IDE", but elsewhere they trumpet the ability of the IDE to interpret and enforce the schema as significant. And again, we can accept that the feature is useful without conceding…

You said "benefit", not advantage.

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

#145

Post by valenterry » Wed, Dec 16, 2020, 3:55 AM UTC

fastball wrote: post #142

valenterry wrote: post #97

Earlier quoted context omitted.

This problem exists in REST APIs in the exact same way though, unless you specifically optimize for this way of querying. But then you can do the same thing with GraphQL, so in the end GraphQL is not worse off, actually rather better because at least the problem exists only between backend and database, not between frontend and backend and database.

The idea is that there is a sort of contract between the backend and the frontend. If I conscientiously create an API endpoint that allows you to fetch articles with their comments, I'm gonna craft that query to avoid the N+1 problem. So when someone uses it, perf isn't scaling linearly. With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything. They say "yay it…

> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything

Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world.

However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments in just one query, so it's much more easy to detect and optimize for that case.

For me, GraphQL wins here.

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

#146

Post by tylergetsay » Wed, Dec 16, 2020, 4:04 AM UTC

mumblemumble wrote: post #86

jensneuse wrote: post #72

Earlier quoted context omitted.

What would you say are the hard things about GraphQL?

Keeping database load under control, for example. With an API that keeps tighter control over access patterns, you've got a more predictable target for optimizing your indexing strategy. With GraphQL, you've got to worry about the possibility that some client figures out how to craft a query that slips between all your indexes and causes the database engine to resort to doing things the hard way. So, worrying about t…

I handle it w/ GraphQL the same way I do with the include query param on a rest endpoint, there's tool to make parsing the query into necessary fields easy.

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

#147

Post by steverb » Wed, Dec 16, 2020, 4:12 AM UTC

14u2c wrote: post #126

steverb wrote: post #45

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. I may also be old and cranky and you should probably get off of my lawn.

There are definitely some cons, but I don't think the learning curve of the query language is one of them. It's simple enough that you can easily pick it up after 15 mins of reading the docs. There is also a schema proved by every server that tells you exactly what can be queried. This is much nicer than having to refer to documentation of unknown quality before you know what a REST api can provide. Now actually impl…

Yeah, it just that with the use case I was exposed to (payment processing) it seemed utterly pointless and overly complex when compared to the rest API.

I don't want to query. I want to submit a transaction for processing dammit.

Again though, it might just be a case of me being old and cranky and having to learn yet another query language.

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

#148

Post by SkyPuncher » Wed, Dec 16, 2020, 4:13 AM UTC

CuriouslyC wrote: post #111

GraphQL is trendy, but unless you need to maintain a lot of different versions of your API it doesn't really seem worth the investment.

We're exploring GraphQL because of the performance benefits of letting the client easily choose what it needs in the response data.

The most prominent use case is lean list views and rich detail views. It's also helpful in views where related data is surfaced in detail.

It can be done with REST, but there are enough edge cases that it's easier to simply follow a standard.

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

#149

Post by fiddlerwoaroof » Wed, Dec 16, 2020, 4:17 AM UTC

talaketu wrote: post #136

dyeje wrote: post #132

Earlier quoted context omitted.

REST endpoints typically return a specific set of data that you can optimize queries for. Whereas the GraphQL endpoint must handle arbitrary queries which will require some logic to prevent N+1 queries on the related tables or even resolve to other data sources.

REST endpoints typically return data I don't need. For example, the twitter REST API `/1.1/users/show.json?screen_name=twitterdev` it will show me the last tweet for the user. Presumably this involves perhaps waiting for tweet service when the client may not even want the tweet. A GraphQL client can be more explicit about what edges to select.

There are specs like jsonapi that solve this problem. I’ve never been entirely convinced that GraphQL is better than actual REST, even if it’s better than most of the APIs people call RESTful

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

#150

Post by gabereiser » Wed, Dec 16, 2020, 4:36 AM UTC

valenterry wrote: post #145

fastball wrote: post #142

Earlier quoted context omitted.

The idea is that there is a sort of contract between the backend and the frontend. If I conscientiously create an API endpoint that allows you to fetch articles with their comments, I'm gonna craft that query to avoid the N+1 problem. So when someone uses it, perf isn't scaling linearly. With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything. They say "yay it…

> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world. However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments…

Same. This is why I was looking for concrete examples because the problem isn’t a graphql problem, it exists in any interface. Kinda a trick question, but it was good reading people’s reasoning ;)