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

201–210 of 243 posts

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

#201

Post by cryptica »

The real cost of GraphQL is resource usage/performance on the backend.

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.

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

#202

Post by dmitriid »

valenterry wrote: post #188
dmitriid wrote: post #187

Earlier quoted context omitted.

> I think you misunderstand. I don't > You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries. What stops a frontend developer writing an ad-hoc query? > Persisted queries enter the game when you define a query that potentially can become very complex and deep That... That is exactly what I wrote. --- Honestly, I'm baffled at GraphQL defenders. It's like they never even read…

> What stops a frontend developer writing an ad-hoc query? What stops them is that the "ad-hoc" query can only look like this: articlesWithComments($id) { title contents comment { author text } } That's all. Now the only way to change this query is to remove fields but there is no way to make anything more complex. The only way to do more is to repeat the query. I.e. literally: article1: articlesWithComment(1) { titl…

> What stops them is that the "ad-hoc" query can only look like this:

What is "author" in that query and why can't the user do

  author {
          name,
          age,
          articles {
            ...
          }
        }
in that query?

And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.

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

#203

Post by valenterry »

dmitriid wrote: post #202
valenterry wrote: post #188

Earlier quoted context omitted.

> What stops a frontend developer writing an ad-hoc query? What stops them is that the "ad-hoc" query can only look like this: articlesWithComments($id) { title contents comment { author text } } That's all. Now the only way to change this query is to remove fields but there is no way to make anything more complex. The only way to do more is to repeat the query. I.e. literally: article1: articlesWithComment(1) { titl…

> What stops them is that the "ad-hoc" query can only look like this: What is "author" in that query and why can't the user do author { name, age, articles { ... } } in that query? And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.

"author" would be the same as in the REST endpoint. So for example a string.

As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server.

Does it answer your questions?

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

#204

Post by tsimionescu »

zwily wrote: post #25

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.

I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly.

On the server side, assuming you have a simple CRUD service in front of a DB, you can probably use a generic GraphQL-to-DB query language library and call it a day. If you have to expose a REST API, you need to understand what's stored in the DB and create some queries, make sure they are performant etc.

Now, if you have a complex service with heterogenous data sources that you want to present homogenously, then both REST and GraphQL will be much more difficult. But even then, with GraphQL you can leave most of the hard work of figuring out how to join efficiently on the client, while with REST it's your responsibility to ensure that the requests execute in a decent amount of time.

In my own company, we use GraphQL for internal communication between a few microservices because we need the flexibility, but we expose a REST API to users, because no one wants to learn how to write queries instead of doing a simple GET on an endpoint we already expose.

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

#205

Post by mcv »

zwily wrote: post #25

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.

This comment tells me exactly what I always wanted to know about GraphQL. I'm working on a project where the front-end needs complex combinations of queries for relations between objects with various properties of different data sets. Our fairly simple REST backend with graph DB provides exactly what the front-end needs, but it does mean there's a tight coupling between the front and back ends.

So every once in a while, the question comes up whether we shouldn't be using GraphQL for this, and every time we end up unsure where to start, how to implement it, or what the actual benefits would be. We control both front and back end, and REST works fine for us.

I guess if we ever want to make our back end usable by other applications, GraphQL might become more useful to us, but until then, it seems like it's mostly a lot of extra work and complexity that we don't need.

GraphQL seems most useful when you're using something that supports it out of the box.

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

#207

Post by dmitriid »

valenterry wrote: post #203
dmitriid wrote: post #202

Earlier quoted context omitted.

> What stops them is that the "ad-hoc" query can only look like this: What is "author" in that query and why can't the user do author { name, age, articles { ... } } in that query? And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.

"author" would be the same as in the REST endpoint. So for example a string. As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server. Does it answer your questions?

So, you're basically proposing to create a poor imitation of REST.

What's the point of GraphQL in this case?

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

#208

Post by collyw »

tsimionescu wrote: post #204
zwily wrote: post #25

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.

I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly. On the server side, assuming you have a simple CRUD service in front of a DB, you can probably use a generic GraphQL-to-DB query language library and call…

> I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly.

This is how I view graphql (despite not having used it). It seems better practice to keep the querying done in the backend and keep frontend for display logic more than anything. Seems like graphql will encourage business logic in the frontend (my current workplace has this problem and it is not something that should be encouraged).

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

#209

Post by collyw »

fiddlerwoaroof wrote: post #149
talaketu wrote: post #136

Earlier quoted context omitted.

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

> even if it’s better than most of the APIs people call RESTful

I feel your pain.

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

#210

Post by valenterry »

dmitriid wrote: post #207
valenterry wrote: post #203

Earlier quoted context omitted.

"author" would be the same as in the REST endpoint. So for example a string. As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server. Does it answer your questions?

So, you're basically proposing to create a poor imitation of REST. What's the point of GraphQL in this case?

I suggest you to take a step back and re-read the thread. Maybe the context got lost. I replied to the following post:

> https://news.ycombinator.com/item?id=25432655

In particular:

> Its much harder to make an efficient resolver than it is making an efficient REST endpoint.

As I showed, the claim is not true because it can be solved in the same way in both GraphQL and REST.

Post reply on HN