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

#161

Post by yashap » Wed, Dec 16, 2020, 6:13 AM UTC

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.

I’m 100% with you. We’ve implemented a GraphQL gateway to our REST APIs at my company, and IMO it’s been a tremendous waste of time. Tonnes of complexity, performance issues, time writing the server, monitoring problems when calls are no longer to simple endpoints, etc., for almost no tangible gain.

Also, a much more minor issue, but when everything is a POST to a single endpoint, debugging network calls in Chrome/whatever dev tools is more of a pain in the ass. It’s a lot easy browsing through GET /users/124, DELETE /messages/456, etc., and instantly see what’s happening, than having every call be POST /graphql, and have to read through all the giant post bodies to figure out what’s going on.

IMO GraphQL is no better than all the other multitude of RPC frameworks that everyone eventually realizes are a snake pits of unnecessary complexity when compared to REST. It’s just newer, so people don’t hate it as much YET.

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

#162

Post by fiddlerwoaroof » Wed, Dec 16, 2020, 6:14 AM UTC

tshaddox wrote: post #156

fiddlerwoaroof wrote: post #149

Earlier quoted context omitted.

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

JSON:API provides some of the same functionality as GraphQL, like specifying which fields and nested resources you want, but at that point you’re going to have the same problems with ensuring good performance with any combination of included fields and relationships.

I don’t disagree: I tend to find REST + openapi codegen a more compelling developer experience then yet another query DSL.

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

#163

Post by nickk314 » Wed, Dec 16, 2020, 6:23 AM UTC

In my experience it's a lot easier to write performant, scaleable, and secure GraphQL API's than REST API's.

Rest is a constant struggle between complexity, functionality and authorisation.

The more flexible a REST API becomes, the more it becomes like GraphQL minus the standardisation.

I wrote a blog [1] on writing GraphQL API's in TypeScript. It focuses particularly on authorisation and relations.

[1] https://dev.to/nickkelly314/writing-a-graphql-typescript-ser...

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

#164

Post by dpeck » Wed, Dec 16, 2020, 6:47 AM UTC

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.

That’s largely the point of it. Graphql allows for a smaller, more focused team to work on the generic backend and lean into the pain of it while at the same time supporting larger and more divergent frontend/user facing teams.

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

#165

Post by baumandm » Wed, Dec 16, 2020, 7:03 AM UTC

gabereiser wrote: post #150

valenterry wrote: post #145

Earlier quoted context omitted.

> 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 ;)

I agree with GP as well, but I do think there are unique circumstances with GraphQL.

One difference is that if the front-end makes N+1 REST calls, it's (hopefully) obvious to the front-end developer. It's also generally easy to map the REST requests to the database queries being made.

Swap it all out for a single GraphQL query and now you have no idea how it will perform or whether it was optimized for the specific fields you are requesting.

Another difference is that REST-style solutions won't work for GraphQL. Imagine you're making a bunch of REST calls, e.g. querying for a list of articles then querying for a list of comments for each one. You can ask the backend team for a new endpoint that returns them all in one query, easy enough.

But with GraphQL schemas, the potential graph of data is too large to write custom SQL queries that efficiently fetch everything in one batch. For example:

  {
    articles {
      title
      contents
      author {
        name
        articles {
          title
          contents
          comments {
            content
            author {
              ...
            }
          }
        }
      }
      comments {
        content
        author {
          name
        }
      }
    }
  }

Maybe a bit contrived, but it illustrates my point. Due to the ability to traverse relationships it's much easier to find yourself in a situation where the implementation of the GraphQL resolvers is not ideal for the usage, but it theoretically will work.

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

#166

Post by dyeje » Wed, Dec 16, 2020, 7:09 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.

Yes, the advantage of a GraphQL endpoint is you can ask for a variety of things and the tradeoff is potential performance issues for unforeseen queries doing N+1s or something.

If you control the API and know all the use cases for a REST endpoint, the advantage is predictable performance characteristics and the tradeoff is flexibility.

It all depends on what you need (and maybe what tools you're using to mitigate GraphQL resolver problems).

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

#167

Post by darepublic » Wed, Dec 16, 2020, 7:13 AM UTC

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

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

#168

Post by mirekrusin » Wed, Dec 16, 2020, 7:14 AM UTC

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.

We use jsonrpc over ws on f/e-b/e and between b/e-b/e services in trading system, typescript types for api, runtime type assertion combinator library for io boundary type checks, backend teams co-maintain client libraries to access the service, it works very fast, it is safe and easy to maintain/track changes etc.

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

#169

Post by ako » Wed, Dec 16, 2020, 7:18 AM UTC

silisili wrote: post #92

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.

Same. But I'm also getting old and cranky. Every advantage typically pointed out over REST could easily be solved in REST. You can do joins in REST people, don't be afraid! I often would add query params for such common things, such as (fake example) fillChildren=true to have what is essentially a parent object populated with its child object in what would normally be separate calls.

True, and this also something OData has as part of the standard. Using a standard way to do this has big benefits, as this knowledge can be implemented in tools (BI, ETL, low-code dev), which can then support many REST endpoints.

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

#170

Post by 14u2c » Wed, Dec 16, 2020, 7:20 AM UTC

dragonwriter wrote: post #131

14u2c wrote: post #128

Earlier quoted context omitted.

There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. When using REST endpoints you are at the mercy an API's documentation, which is often quite poor. I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL.

> There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. So, commonly, does a REST endpoint that observes HATEOAS (without which it is not REST.) > I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL. REST is an architectural style, not a standard, but i…

Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. If a product advertise a GraphQL api you know immediately there will be no trouble with determining what the api can return and accept.