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

121–130 of 243 posts

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

#121

Post by atom_arranger »

ehutch79 wrote: post #4
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…

You do realize there's no reason a rest endpoint can't support doing this. My endpoints take a 'fields' parameter... and those fields can themselves be serialized objects.

The problem with this is the “my endpoint” part.

This functionality is automatically part of every GraphQL API, and it is consistent.

The same issue applies to types and documentation, you can do it with REST, but it’s inconsistently done.

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

#123

Post by WiseWeasel »

baumandm wrote: post #30
gabereiser wrote: post #18

Earlier quoted context omitted.

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

If that’s a problem, have the frontend run a separate query for the article’s comments upon expansion of the section, like the REST version would have done. You still have easier caching in the GQL version.

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

#124

Post by altrunox »

postalrat wrote: post #118
xupybd wrote: post #96

Earlier quoted context omitted.

Could you elaborate please. I don't understand the issue surely you could model this on the backend and serve it via GraphQl?

I think he is saying graphql doesn't have recursion.

Well yes, that would be a better way to say it, no recursively nested objects, there is a Github discussion about it here:

https://github.com/graphql/graphql-spec/issues/91

And if someone else is interested to take a look at my clone project (it's in Clojure), for the GraphQL issue you can search for "request recursively nested objects".

https://www.giovanialtelino.com/project/hacker-news-graphql/

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

#125

Post by valenterry »

anamexis wrote: post #112
valenterry wrote: post #94

Earlier quoted context omitted.

The n+1 would be there with REST too. Unless you have specific, optimized REST routes - but then you can do the same with specific, optimized graphQL queries too.

Well, I would argue with "true" REST, all of your REST routes are specific, and generally therefore easy to optimize.

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

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

#126

Post by 14u2c »

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 implementing a server on the other hand is much more difficult.

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

#127

Post by floydnoel »

jayd16 wrote: post #95
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 is the strange thing about GraphQL, it shifts the work to someone else so you'll end up with people teams that benefit and teams that don't. You also need opt in from both the client and server. I wish there was a client side library that implemented GraphQL as an abstraction over REST, GraphQL or other backend APIs. It would be nice to use some of the GraphQLs query/join features across several backend services…

Gatsby does this, and I’ve built a POC that did the same thing to try to get my workplace to adopt it. I shelved it after a demo as I didn’t love the idea of maintaining a bespoke API solution. But I’m with you, I think it’s a great idea if there were a community around it.

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

#128

Post by 14u2c »

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.

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.

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

#129

Post by axaxs »

14u2c wrote: post #128
silisili wrote: post #92

Earlier quoted context omitted.

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.

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.

That's a good point as API doc is often very, very wrong. Still, this could just as easily be added as some semi standardized REST extension/spec. Granted, it wouldn't have the traction up front GQL gives you.

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

#130

Post by systemvoltage »

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 user focused. GraphQL is like opening up the entire machine, stripping off the panels and working on live circuits.

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.

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.

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

Post reply on HN