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

11–20 of 243 posts

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

#11

Post by verdverm »

jiofih wrote: post #8
ehutch79 wrote: post #4

Earlier quoted context omitted.

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.

Very lazy thinking. It doesn’t have types, do introspection, batching, granular caching, access control... I suggest reading the GraphQL introduction post for a start: https://engineering.fb.com/2015/09/14/core-data/graphql-a-da...

These things have overhead and access control is more difficult to reason about and implement with resolvers and nested query resolving.

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

#12

Post by ehutch79 »

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.

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

#13

Post by the_arun »

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…

Regarding decoupling GraphQL from HTTP - do we need this? cause are there plans to use GraphQL on different protocols like raw TCP? Isn't GRPC better for raw TCP?

When we are using HTTP, diluting HTTP standards - eg. using POST for both creating & updating, returning HTTP 200 for errors seem to be hacky in GraphQL.

I always found REST to be more simple & straight forward. With progression in HTTP itself - HTTP/2, HTTP/3 etc., chatty behavior of REST may not be expensive.

Implementing roles & permissions in GraphQL tricky. We need clear schema definitions to control it. Huge learning curve as well.

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

#14

Post by zanellato19 »

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

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

#16

Post by chris_st »

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

This is definitely my experience, particularly in using Hasura (particularly via the wonderful NHost[0], a fantastic database service). I believe that Hasura knows how to not do N+1 queries.

[0] https://nhost.io

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

#17

Post by vmware513 »

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.

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

#18

Post by gabereiser »

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…

Can you give some concrete examples on the N+1 problem? I’ve heard this before but never experienced it.

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

#19

Post by recursivedoubts »

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 & application logic changes are made[1].

I'm glad to see javascript client-server apps heading this direction, and leaving REST/HATEOAS to hypertext-oriented approaches[2].

REST sans a hypertext was always a mistake.

[1] - https://www.infoq.com/articles/no-more-mvc-frameworks/

[2] - https://htmx.org

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

#20

Post by enobrev »

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

For instance:

    "query": [
       "/api/category/books/products",
       "/api/products/{products.id}/images",
       "/api/products/{products.id}/reviews",
       "/api/users/{reviews.user_id}"
    ]
When the endpoint gets this query, it will run a GET on the first endpoint. And then it uses the results from that first endpoint to fill in the uri template on the 2nd endpoint, which would become something like "/api/products/2,4,17/images". And the results of all previous endpoints are merged into the response and can be used to fill subsequent uri templates as well.

As far as the client is concerned this is all done in a single API request. The first version was making literal HTTP requests to localhost, but now is built to call the endpoints directly (internally, no HTTP). This system requires some convention in the responses to make it work, but that convention ends up making responses predictable and easily reusable. Overall it's worked very well and requires almost no additional effort.

I have a similar endpoint that also allows "POST"s which makes for seriously complex single-request interactions, but I don't use that as much due to the inherent complexity of it - at least not for client-side APIs.

When I first looked into GQL, it looked pretty fancy, but seemed to require quite a bit more maintenance to define the query space. This was before a lot of today's libraries were available. So I hacked together the Multi-Endpoint Query, assuming if it failed, I could go back to GQL when there were more libraries available. But I haven't really needed to do so since.

Post reply on HN