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

131–140 of 243 posts

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

#131

Post by dragonwriter »

14u2c wrote: post #128
silisili wrote: post #92

Earlier quoted context omitted.

Same. But I'm also getting old and cranky. Every advantage typically pointed out over REST could easily be solved in REST. You can do joins in REST people, don't be afraid! I often would add query params for such common things, such as (fake example) fillChildren=true to have what is essentially a parent object populated with its child object in what would normally be separate calls.

There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. When using REST endpoints you are at the mercy an API's documentation, which is often quite poor. I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL.

> There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried.

So, commonly, does a REST endpoint that observes HATEOAS (without which it is not REST.)

> I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL.

REST is an architectural style, not a standard, but it is baked into the description of the architectural style.

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

#132

Post by dyeje »

valenterry wrote: post #125
anamexis wrote: post #112

Earlier quoted context omitted.

Well, I would argue with "true" REST, all of your REST routes are specific, and generally therefore easy to optimize.

Why would your routes with REST magically be specific and your queries with GraphQL not?

REST endpoints typically return a specific set of data that you can optimize queries for. Whereas the GraphQL endpoint must handle arbitrary queries which will require some logic to prevent N+1 queries on the related tables or even resolve to other data sources.

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

#133

Post by preommr »

14u2c wrote: post #128
silisili wrote: post #92

Earlier quoted context omitted.

Same. But I'm also getting old and cranky. Every advantage typically pointed out over REST could easily be solved in REST. You can do joins in REST people, don't be afraid! I often would add query params for such common things, such as (fake example) fillChildren=true to have what is essentially a parent object populated with its child object in what would normally be separate calls.

There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. When using REST endpoints you are at the mercy an API's documentation, which is often quite poor. I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL.

I am pretty sure there's something about REST that makes it so that it's easy to discover what resources are available.

I just pulled up Fielding's paper and couldn't find anything, but wikipedia has a reference to 'Hypermedia as the engine of application state' (HATEOAS).

But then again, I am not sure anyone actually writes systems like this. Very few people actually write REST systems and instead make REST-like APIs.

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

#134

Post by t-writescode »

recursivedoubts wrote: post #87
t-writescode wrote: post #79

Earlier quoted context omitted.

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

The language here is getting a little squirrly. "Can't be a hypertext" is too restrictive. "Isn't a hypertext" is how I would say it. JSON as JSON isn't a hypertext in the same way that XML as XML isn't a hypertext. XHTML is a hypertext based on XML. (HTML itself isn't proper XML.) There are hypertext specs based on JSON, such as: https://json-schema.org/draft-04/json-schema-hypermedia.html But, without clients that…

Thank you for clarifying your stance

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

#135

Post by btilly »

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…

Use something like Postgraphile to create your graphql endpoint and it will issue a single query then massage the results into what it needs them to be.

I don't see this as a major problem.

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

#136

Post by talaketu »

dyeje wrote: post #132
valenterry wrote: post #125

Earlier quoted context omitted.

Why would your routes with REST magically be specific and your queries with GraphQL not?

REST endpoints typically return a specific set of data that you can optimize queries for. Whereas the GraphQL endpoint must handle arbitrary queries which will require some logic to prevent N+1 queries on the related tables or even resolve to other data sources.

REST endpoints typically return data I don't need. For example, the twitter REST API `/1.1/users/show.json?screen_name=twitterdev` it will show me the last tweet for the user. Presumably this involves perhaps waiting for tweet service when the client may not even want the tweet. A GraphQL client can be more explicit about what edges to select.

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

#137

Post by haimez »

cogman10 wrote: post #102
mumblemumble wrote: post #86

Earlier quoted context omitted.

Keeping database load under control, for example. With an API that keeps tighter control over access patterns, you've got a more predictable target for optimizing your indexing strategy. With GraphQL, you've got to worry about the possibility that some client figures out how to craft a query that slips between all your indexes and causes the database engine to resort to doing things the hard way. So, worrying about t…

The trick is to abstract away what can make the DB tip over. This complicates your servers, for sure, but pays dividends on performance/scale. How do you do that? https://github.com/graphql/dataloader However, to be super efficient you need to give up on some consistency. You simply can't have data points which join directly in the db. Instead, you need to make separate parallel requests for those datapoints and let…

> Instead, you need to make separate parallel requests for those datapoints and let the dataloader be in charge of merging them into larger batches of requests for the db to fullfill. > This can result in some additional latency on a request, but ultimately provides the best way to be able to scale things out.

I promise you, this is not the best way to scale things out.

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

#138

Post by vyrotek »

Out of all the API implementations I've created in my career I've had the most success implementing BFF (Backends for Frontends) with simple RPC'ish endpoints. Everything else never quite fit right and wasted so many hours.

https://samnewman.io/patterns/architectural/bff/

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

#139

Post by adamkl »

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…

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 think of it as an “ORM” for the browser, which seems cool, but I wouldn’t necessarily recommend this approach (though I have done it in the past) for two reasons:

1. The “graphql” library isn’t really optimized for size so it can add a bunch of overhead to your JavaScript bundles

2. One of the benefits of GraphQL is to combine multiple requests for related data into a single query to be sent from the browser. Yes, that makes the life of the backend developer harder as they try to optimize for performance, but it makes for less data/fewer requests over the wire to the client. If you stick GraphQL in the browser, you’ve now just moved your N+1 query across the internet.

If you really want to go down that road, Apollo offers a “plugin” to their GraphQL client that allows you to call multiple REST endpoints as if they were a single GraphQL endpoint (without embedding the actual “graphql” library in the browser): https://www.apollographql.com/docs/link/links/rest/

A better approach for what you’re looking for would be to schema stitching (which allows you to combine multiple GraphQL endpoints together and treat them as one. You can even combine that with your own schema definitions to mix in whatever backend sources you want; e.g. your vendor + FedEx REST APIs): https://www.graphql-tools.com/docs/stitch-combining-schemas

Or if you don’t want to do the work yourself, check out OneGraph, which uses schema-stitching to do exactly what you describe. It’s pretty cool: https://www.onegraph.com/

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

#140

Post by fastball »

vyrotek wrote: post #138

Out of all the API implementations I've created in my career I've had the most success implementing BFF (Backends for Frontends) with simple RPC'ish endpoints. Everything else never quite fit right and wasted so many hours. https://samnewman.io/patterns/architectural/bff/

Isn't that effectively what GraphQL is supposed to be?
Post reply on HN