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

71–80 of 243 posts

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

#71

Post by dragonwriter »

ClumsyPilot wrote: post #69
recursivedoubts wrote: post #43

Earlier quoted context omitted.

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

> 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 browsers do, since REST is the key principal underlying the design of HTTP/1.1 and was largely a rationalization of the evolved behavior of the web per-HTTP/1.1.

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

#72

Post by jensneuse »

mumblemumble wrote: post #60
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.

My sense is that GraphQL makes the impossible stuff hard and the easy stuff hard. So its relative merits have a lot to do with how complicated a thing you're trying to do in the first place.

What would you say are the hard things about GraphQL?

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

#73

Post by mumblemumble »

jaredklewis wrote: post #37
treve wrote: post #29

This paper has a pretty naive understanding of REST. While 'REST' can mean something different depending on who you talk to, I think in the context of a paper we can expect a bit more research. This paper takes a typical query, and just overlays it on a CRUD-style REST endpoint, but it ignores: * REST can definitely be strongly typed. There's OpenAPI, and JSON-Schema. In many instances I think this will work better t…

> To be fair, many APIs are just that. My experience is that almost all REST APIs are like that, give or take some documentation. Though I have read about both, I have never worked with a JSON schema or Open API api. I have conservatively worked at least a hundred REST APIs, including both public and private ones. I’m mildly optimistic about GraphQL, but without a doubt I think one of the best parts is that all Graph…

> Some people like more restrictive languages, because they don’t trust others or themselves to reliably use good discretion in the use of powerful features

For me, it's not even that. It's that I've discovered that, even when used with discretion, the simple presence of powerful features still makes it harder to reason about how things work. Discretion around powerful features isn't a one-and-done thing; it's an ongoing process of double-checking and verifying for yourself whether that feature is being used properly every time you touch or interact with code that uses it.

A common thread in many seminal papers and essays in the history of programming languages ("Can Programming be Liberated from the Von Neumann Style", "GOTO Statement considered harmful", "Lambda: The Ultimate GOTO", to name a few.) is that, ironically enough, when you take a bird's eye look at things, reducing the power of the tools tends to increase the power of the programmer.

I should say, I'm not meaning that to be a statement in favor of static or dynamic typing; I try to stay out of that debate.[1] To me, the real problem with JSON is that, at least under typical usage, it tends to be weakly typed. (Which is a powerful feature; strong typing is a way of restricting what you can do.) JSON's type system is less expressive than that of basically any well-known programming language, including JavaScript itself, and, out of necessity, people tend to deal with that by overloading its types in ways that may force consumers to use out-of-band knowledge to interpret a message properly. This has a tendency to happen even in the presence of OpenAPI specs or JSON schemata.

[1] Though I'll take this chance to link https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...

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

#75

Post by jensneuse »

brimstedt wrote: post #64

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

The problems you described can be easily solved: https://wundergraph.com/features/caching What you gain is the flexibility of GraphQL together with the performance and cacheability of REST.

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

#76

Post by recursivedoubts »

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

Earlier quoted context omitted.

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?

It has a hypermedia spec:

https://www.w3.org/TR/html4/

And a bunch of things called "browsers" that implement that spec. More or less.

I mean, come to that, aren't XML and HTML both just text? Isn't text, then, a hypertext? One can embed URLs in text, after all...

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

#77

Post by valeness »

zachrip wrote: post #39
baumandm wrote: post #30

Earlier quoted context omitted.

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…

The solution for this is to use something like dataloader btw. It essentially waits for all these queries (I believe it uses queueMicrotask under the hood) and batches them. Not unlike other db batching proxies.

Wouldn't it be more resource efficient to traverse the graph ahead of time and prefetch all related resources with a single query?

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

#78

Post by bengale »

boublepop wrote: post #41
zachrip wrote: post #34

Earlier quoted context omitted.

I think REST is definitely playing catch up here though. A standard gql setup generally comes out of the box with type generation, web playgrounds, etc. Of course it's possible now with REST but I really think that gql helped push the state of the art in this space.

We’ve had these aspects out of the box with oData REST endpoints that have been in production for half a decade.

What do you think may account for the lack of take up iof oData?

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

#79

Post by t-writescode »

recursivedoubts wrote: post #76
t-writescode wrote: post #68

Earlier quoted context omitted.

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

It has a hypermedia spec: https://www.w3.org/TR/html4/ And a bunch of things called "browsers" that implement that spec. More or less. I mean, come to that, aren't XML and HTML both just text? Isn't text, then, a hypertext? One can embed URLs in text, after all...

Does this mean that your argument that json can't be a hypertext is because it doesn't already have a universal hypermedia spec?

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

#80

Post by tsss »

enobrev wrote: post #20
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're not wrong, and to resolve this, I've implemented something of an in-between for APIs I work on, which I call a "Multi-Endpoint Query". It's a restful(-ish) API, but there's an additional endpoint called "query", which allows for an array of endpoints to gather information from sequentially. The most useful bit of this is that information gathered from earlier in the array can be used as referenced later in the…

This is an API gateway or backend-for-frontend.
Post reply on HN