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

231–240 of 243 posts

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

#231

Post by ar_lan »

collyw wrote: post #211
ar_lan wrote: post #52

Earlier quoted context omitted.

Your response is to the typing nature of GraphQL, but this isn't the only strong reason for GraphQL. GraphQL reduces both response payload size to only what is necessary for the client, but also reduces round-trips. Unless you are writing custom REST endpoints for every aspect of your UI, most formulation of what data a consumer needs will usually resolve in multiple trips to the server. So, you either scale out by h…

> Unless you are writing custom REST endpoints for every aspect of your UI Wouldn't that be the normal way to implement a REST API?

The problem is you might end up writing strange endpoints just to satisfy a specific UI page.

For example, take a small blog, that holds several posts, each with an author.

In GraphQL, you could fetch all the posts, and all info related to the author in the same query (without any new, funny business).

In REST, if you wanted this in a single query, you'd need to define some endpoint like /post-and-authors-list that fetches all the posts and complete author information for each post, whereas most REST implementations would probably involve a small set of CRUD steps on all posts, and then several queries to fetch each author for further information as well (based on the author ID in the post).

So it's not that REST can't implement anything GraphQL wants to implement, but there is a lot more work involved, is harder to scale out with developers, etc.

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

#232

Post by kurko »

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…

Although not GraphQL, that's the idea behind Ember-Data. The API is slightly different but you access data from serialized objects.

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

#233

Post by busfahrer »

adamkl wrote: post #139
jayd16 wrote: post #95

Earlier quoted context omitted.

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…

There’s actually nothing server specific about GraphQL. The specification makes no mention of transport layer, it’s simply a type system + query executor. You can pretty easily (if you have experience with the GraphQL reference implementation in JavaScript) create a GraphQL layer that sits inside of the browser, with a schema created by the UI team, that executes calls to REST APIs to resolve the data. You could thin…

> There’s actually nothing server specific about GraphQL.

I just grokked this very recently when I was reading up on Gatsby and the fact that they use GraphQL. I was confused for a bit because Gatsby is SSG, until I realized they merely use GraphQL as a generic way to query any JSON data you might have laying around, similarly to how getStaticProps() is employed in NextJS

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

#234

Post by systemvoltage »

lukeramsden wrote: post #199
systemvoltage wrote: post #130

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…

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

That's very helpful, thank you!

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

#235

Post by ehutch79 »

xupybd wrote: post #98
ehutch79 wrote: post #12

Am I missing something, or was this only about implementing queries with a fixed backend? What's the numbers on implementing these? In different languages other than javascript? Last time I looked, implementing graphQL with django was pretty janky and limited.

Try Hasura. If you have a database centric architecture you get most of the heavy lifting done for you. Slap in keycloack and you have auth sorted. It doesn't do everything but it's a good way to play with GraphQL

How does it handle column and row based permissions?

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

#236

Post by luisramalho »

mumblemumble wrote: post #225
luisramalho wrote: post #110

Earlier quoted context omitted.

Do you mean "GraphQL makes the impossible stuff easy "? If so, I do agree with that statement.

No, but I realize it sounded like a typo. Perhaps, in retrospect, a cleverer wording would have been, "makes impossible things possible and easy things. . . possible." Perhaps that's my bias showing. Lately I've mostly been working in Java, a context where the words "easy" and "Web" rarely belong together in the same sentence.

> "makes impossible things possible and easy things. . . possible."

I like that one! Yeah, I totally thought it was a typo, but I do think that GraphQL makes very complicated things easy. I might also be biased because I've been working with it for a while now.

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

#237

Post by acidbaseextract »

dragonwriter wrote: post #71
ClumsyPilot wrote: post #69

Earlier quoted context omitted.

So far I have not experienced HATEOAS deliver value over a wiki with good documentation - that seems like better effort.

> I have never seen how does HATEOAS deliver benefit over a wiki with good documentation - that seems like better effort. Have you used a web browser? Do you see how it handles known content types from a new website that you haven't previously visited seamlessly without you reading docs and telling it what to do with it? That is exactly HATEOAS. In general, understanding REST is often easiest if you think about what…

> Have you used a web browser? Do you see how it handles known content types from a new website that you haven't previously visited seamlessly without you reading docs and telling it what to do with it?

I want to get my job done with an API, not browse it. I spend most of my time figuring out what order endpoints need to be called in and what data they need to be passed, not what the endpoints are.

The shittiest HTTP APIs I've used had full lists of endpoints but nonexistent documentation of arguments. If HATEOAS solves that I can get behind it, but I don't think it does.

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

#238

Post by intellix »

jasonhero wrote: post #51

As someone who has heavily used both REST and GraphQL in the past and actively, I find this comparison heavily similar to using raw HTML versus React. When it really boils down, GraphQL is just REST with types and the capability of performing multiple requests in one. Much like React is a way of creating component types from HTML elements. GraphQL takes a bit more work to get setup and running, but it's soo worth it…

well it's literally just a tree of functions with extra metadata to make it extra powerful. Also have used both REST and GQL heavily and it essentially solves lots of problems I had with REST. I'm never writing REST again and when I see that something I'm consuming also have a GQL API it makes me so happy to be able to know every single field available to me.

The only use-case where it's annoying me is a CMS for building an entire site. It's recursive as A -> B -> A -> B and the lack of recursion as of yet makes it manual work to extract every level that you need.

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

#239

Post by valenterry »

dmitriid wrote: post #228
valenterry wrote: post #210

Earlier quoted context omitted.

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.

> I suggest you to take a step back and re-read the thread. Maybe the context got lost. I've read the thread. And no, the context wasn't lost. The whole point of GraphQL is flexible queries. And it is harder to make an efficient resolver in GraphQL than it is in REST. And yes, your solution (and the solution everyone ends up arriving at) is reimplementing REST in GraphQL, poorly. Precisely because it is much harder t…

I think I have proven my point and I'm not eager to discuss additional topics about GraphQL in this subthread.

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

#240

Post by 14u2c »

jillesvangurp wrote: post #190
14u2c wrote: post #126

Earlier quoted context omitted.

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…

I introduced graphql a few months ago to basically unblock myself from having to think about and design gazillions of custom REST endpoints for our mobile client developers. Turns out, that I don't miss doing that. REST has been a huge drain intellectually on this industry ever since people got pedantic over Roy Fielding's thesis and insisted that we stop treating HTTP like yet another RPC mechanism. The amount of de…

I'm also using a Java / Kotlin based solution with java-dataloader [0] and have been quite pleased with the performance.

[0]: https://github.com/graphql-java/java-dataloader

Post reply on HN