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

31–40 of 243 posts

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

#31

Post by clusterhacks »

recursivedoubts wrote: post #19

The results are intuitive and in favor of GraphQL, especially as query complexity increases. GraphQL makes loads of sense for modern javascript thick clients: The front end developer is going to want the same thing that a back end developer has: an expressive, general query language. And the API developer should want to give it to them so they aren't dragging their API around all over the place as fiddly UI & applica…

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 than a well-defined representation with embedded hyperlinks. Every consumer I heard about simply parsed the JSON bits they wanted from responses and hard-coded URL links in their client apps.

I enjoyed the design and writing of the app - I used Clojure and the liberator library. Probably a wasted effort of engineering in the end. Totally fun project to implement though.

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

#32

Post by cratermoon »

treis wrote: post #24
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…

There's no law against putting joined data into a REST endpoint. As an example, I had to consume an API for a customer's subscriptions. They did it by the book where Customer has Subscriptions which has Items which has Prices. That was a huge performance issue for us because it was 4 round trips. But they didn't need to use GraphQL. They just needed a fullDetails end point for subscriptions.

In DDD this is the Aggregate pattern. https://martinfowler.com/bliki/DDD_Aggregate.html

Essentially, a graph of objects that must be treated as a single entity.

I've seen quite a few REST implementations that have separate calls for the root and branches, like Order and LineItems. In the Aggregate pattern, you treat them as an entity that travels and transacts as one.

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

#34

Post by zachrip »

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…

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.

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

#35

Post by coding123 »

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…

And there's nothing wrong with that. You essentially invented your own GQL because it contained some awesome ideas. Also I think it would be OK if new things similar to GQL came out and challenged it. I don't think GQL is perfect, and I personally wish it had namespacing and more thought about caching built in.

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

#36

Post by mssundaram »

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…

Given your example request, what would be the schema of the response?

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

#37

Post by jaredklewis »

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 GraphQL APIs have typed schemas. There is no discretion on the part of the API provider.

This is similar to a debate regarding programming languages. 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 or omission of optional safety checks like types.

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

#38

Post by Technically »

zanellato19 wrote: post #14
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,…

I have the opposite experience working on the backend. GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored. Its much harder to make an efficient resolver than it is making an efficient REST endpoint. Errors are harder, because HTTP codes are not used and monitoring is a lot more complicated. I see value in GraphQL - but I think it brings a lot of cost to th…

> GraphQL is too prone to N+1s and other inefficiencies because its in direct opposition of the way data is stored.

A GraphQL server stack makes a lot more sense when you structure the data around the queries you want to make. This often isn't realistic when converting an existing relational model. There's an inherent tradeoff with the backend you use between SQL-like querying and GraphQL-like querying—they're built around different use cases. I'd recommend approaching GraphQL data modeling around the indexes used to support the queries you want to use—you can then bound (and, if you want, restrict) the resulting number of backend queries based on the input query, not the backing data.

However, this would represent large shift from using an ORM dedicated to SQL access for many developers.

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

#39

Post by zachrip »

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…

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.

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

#40

Post by murukesh_s »

zachrip wrote: post #34
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…

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.

huh! Swagger playground is there at least one year before[1] gql was used internally in Facebook and several years before it was available publicly..

[1] https://en.wikipedia.org/wiki/Swagger_(software) [2] https://en.wikipedia.org/wiki/GraphQL

Post reply on HN