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

61–70 of 243 posts

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

#61

Post by t-writescode »

recursivedoubts wrote: post #48
t-writescode wrote: post #42

Earlier quoted context omitted.

Could you define your terms? Especially: * uniform interface * hypertext And even more especially how JSON does not meet the requirements?

Uniform interface: https://en.wikipedia.org/wiki/Representational_state_transfe... Hypertext: https://en.wikipedia.org/wiki/Hypertext JSON is obviously not a native hypertext, any more than plain text or CSV is. You can, of course, embed URLs in it (or any other format) and call it a hypertext. That's usually pointless, as the links will be consumed by code (rather than a human, in the canonical HTML->browser interac…

Curious to me is that it seems you argue that XML is a valid hypertext; but, isn't it possible to implement most any valid xml document as a json document, even considering attributes?

And, have you seen Github's API implementation? They have the links and self-referential details in their particular json schemas that you seem to imply are necessary and unique for that.

If the argument is that json can't be rendered, isn't it arguable that xml equally has that problem, we just have a program with a common syntax reader format that renders pages equivalently, and something equivalent could be written for a particular json schema?

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

#62

Post by cratermoon »

gsvclass wrote: post #54

The site 42papers.com that serving this link is build with Super Graph a GraphQL to SQL compiler. Tech like this makes GraphQL clearly the easier, faster and better option. I built Super Graph since I wanted something better than REST while building apps and did not want to go down the rabbit hole of GraphQL frameworks where I would still need to write and maintain all the database query code for the app. I started o…

I just looked at Categories list there at https://42papers.com/categories and WOW is it broken.

Examples:

Social and Information Networks category description is: Covers all aspects of computing with sound, and sound as an information channel. Includes models of sound

But over in Audio and Speech Processing the description says: General methodological and applied contributions to economics.

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

#63

Post by gsvclass »

cratermoon wrote: post #62
gsvclass wrote: post #54

The site 42papers.com that serving this link is build with Super Graph a GraphQL to SQL compiler. Tech like this makes GraphQL clearly the easier, faster and better option. I built Super Graph since I wanted something better than REST while building apps and did not want to go down the rabbit hole of GraphQL frameworks where I would still need to write and maintain all the database query code for the app. I started o…

I just looked at Categories list there at https://42papers.com/categories and WOW is it broken. Examples: Social and Information Networks category description is: Covers all aspects of computing with sound, and sound as an information channel. Includes models of sound But over in Audio and Speech Processing the description says: General methodological and applied contributions to economics.

The categories are from ARXIV this is how they have defined stuff. I'm working on adding our own tag layer on top. https://arxiv.org/category_taxonomy

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

#64

Post by brimstedt »

I think one problem of gql relates to caching.

Using rest, it's dead easy to enable caching on load balancer or CDN level with background updates.

But with graphql- it's not so trivial. Youll have to do workarounds by caching POST requests (which imo is bad practice) or use GET requests, which might not work because the URL gets too long.

Or use named queries, but then - what did you gain compared to rest?

Another problem is that you expose internals and may more easily make yourself vulnerable to overload attacks.

My two ören

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

#66

Post by altrunox »

A while ago I decided to build another one of those Hacker News clone, and decided to use GraphQL, everything was fine, until I got at the comments...

You cannot ask for all the children of a main comment or a thread, something like "give me all the comments and sub comments of thread X" is impossible, I was quite shocked because I read nowhere about this limitation, I solved it adding an extra field to my response adding a "father" field, so I needed to organize and sort the data at the front-end, instead of using an already sorted JSON like would be possible with rest.

With all due respect, I find that most of GraphQL tests and examples return mostly simple data that is kinda easy anyways.

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

#67

Post by recursivedoubts »

t-writescode wrote: post #61
recursivedoubts wrote: post #48

Earlier quoted context omitted.

Uniform interface: https://en.wikipedia.org/wiki/Representational_state_transfe... Hypertext: https://en.wikipedia.org/wiki/Hypertext JSON is obviously not a native hypertext, any more than plain text or CSV is. You can, of course, embed URLs in it (or any other format) and call it a hypertext. That's usually pointless, as the links will be consumed by code (rather than a human, in the canonical HTML->browser interac…

Curious to me is that it seems you argue that XML is a valid hypertext; but, isn't it possible to implement most any valid xml document as a json document, even considering attributes? And, have you seen Github's API implementation? They have the links and self-referential details in their particular json schemas that you seem to imply are necessary and unique for that. If the argument is that json can't be rendered,…

I do not think that XML is a hypertext. So I agree with you.

HTML is a hypertext.

Yes, Github probably has one of the most as-REST-like-as-possible JSON apis, and it's mostly wasted effort. It would be just as usable, as an API, without all that stuff, since it is consumed by code, not a browser/human.

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

#68

Post by t-writescode »

recursivedoubts wrote: post #67
t-writescode wrote: post #61

Earlier quoted context omitted.

Curious to me is that it seems you argue that XML is a valid hypertext; but, isn't it possible to implement most any valid xml document as a json document, even considering attributes? And, have you seen Github's API implementation? They have the links and self-referential details in their particular json schemas that you seem to imply are necessary and unique for that. If the argument is that json can't be rendered,…

I do not think that XML is a hypertext. So I agree with you. HTML is a hypertext. Yes, Github probably has one of the most as-REST-like-as-possible JSON apis, and it's mostly wasted effort. It would be just as usable, as an API, without all that stuff, since it is consumed by code, not a browser/human.

What does HTML have that XML doesn't have? Isn't XML a superset of HTML?

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

#69

Post by ClumsyPilot »

recursivedoubts wrote: post #43
clusterhacks wrote: post #31

Earlier quoted context omitted.

I designed a REST API with a "well-documented" HATEOAS representation (collection+json). The primary requirement was to ensure there was no caller-side language dependency because we had multiple teams that would be calling the API and those teams might use the command line, Python, Ruby, Javascript, etc clients to consume the API results. API adoption was low in the end - teams in the end wanted libraries rather tha…

> Every consumer I heard about simply parsed the JSON bits they wanted from responses and hard-coded URL links in their client apps Exactly. HATEOAS is for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

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

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

#70

Post by emilecantin »

vmware513 wrote: post #17
emilecantin wrote: post #10

As someone who's worked with both approaches, at all levels of the stack (both backend and frontend), I think the paper (at least, its abstract) is missing the point. While I do "feel" faster when working with GraphQL, I think the main benefit is that it abstracts away the busywork of transferring data between frontend and backend. Writing a backend becomes more about describing what data is available, on what terms,…

Agree, a good library on frontend level simplify the whole development process. Ember Data solves almost everything so you can focus on features and deliver the app in no time.

Sounds interesting, is it tied to Ember or does it just share the name?

That's one thing that's great about Apollo; it's not too tied to any other tech / framework (except GraphQL, of course).

Post reply on HN