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

211–220 of 243 posts

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

#211

Post by collyw »

ar_lan wrote: post #52
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…

Your response is to the typing nature of GraphQL, but this isn't the only strong reason for GraphQL. GraphQL reduces both response payload size to only what is necessary for the client, but also reduces round-trips. Unless you are writing custom REST endpoints for every aspect of your UI, most formulation of what data a consumer needs will usually resolve in multiple trips to the server. So, you either scale out by h…

> Unless you are writing custom REST endpoints for every aspect of your UI

Wouldn't that be the normal way to implement a REST API?

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

#212

Post by Aeolun »

collyw wrote: post #208
tsimionescu wrote: post #204

Earlier quoted context omitted.

I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly. On the server side, assuming you have a simple CRUD service in front of a DB, you can probably use a generic GraphQL-to-DB query language library and call…

> I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly. This is how I view graphql (despite not having used it). It seems better practice to keep the querying done in the backend and keep frontend for display…

It is really hard to do business logic in GraphQL. The language syntax is literally limited to ‘I want this data’.

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

#213

Post by Aeolun »

plif wrote: post #160
adamkl wrote: post #139

Earlier quoted context omitted.

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

I don't think #2 is that big of a deal if all requests happen async, which they should with a client side ORM, and if you're using http2. I think the bigger problem there is how those multiple REST calls map to your data stores. Very rarely will there be clean separation of data between endpoints, and the stateless nature of REST makes it harder to optimize each call -- meaning, there will almost certainly be redunda…

If you cache enough, your frontend dev can call as many things as they want and it will still be more or less instant.

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

#214

Post by FriedrichN »

mirekrusin wrote: post #168
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.

We use jsonrpc over ws on f/e-b/e and between b/e-b/e services in trading system, typescript types for api, runtime type assertion combinator library for io boundary type checks, backend teams co-maintain client libraries to access the service, it works very fast, it is safe and easy to maintain/track changes etc.

JSON-RPC is my protocol of choice as well. I feel most of these other protocols are mostly an exercise in information exchange theory which make them too idealistic, resulting in poor implementations that do not follow the standard or are extended in non-conforming ways.

In the end you simply want to interact with the client or server and procedure calls do just that. I honestly do not see the use in over complicating that.

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

#215

Post by tsimionescu »

Aeolun wrote: post #212
collyw wrote: post #208

Earlier quoted context omitted.

> I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly. This is how I view graphql (despite not having used it). It seems better practice to keep the querying done in the backend and keep frontend for display…

It is really hard to do business logic in GraphQL. The language syntax is literally limited to ‘I want this data’.

Well, when you say 'give me all cars and all users joined by user ID = owner id', that's business logic. With a good REST API you would just do a GET on /cars and find any user details that are needed already in each car (perhaps under a link, which may lead to the N+1 problem, but that's another discussion).

Of course, a bad REST API may expect that you do a GET /cars and GET /users and match them in your code, which is once again business logic in the front-end and bad design. There are even many DB-To-Rest libraries that encourage exactly this, unfortunately.

A good GraphQL API could also allow you to query cars and get car.Owner.Name and car.Owner.Address without you explicitly joining (the join still happens in the backend). However, I feel that many people who choose GraphQL are trying to avoid exactly this type of logic on the backend, which would explain the popularity of DB-to-GraphQL libraries.

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

#216

Post by KuhlMensch »

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.

My take:

GraphQL allows (limited) queries from the client.

GraphQL unlocks Frontend-acting-as-Product, or Product

At the cost of (hopefully) a smartly written decorator, a schema-based boilerplate, or a bunch of resolvers. And surely, I guess some raw performance and enforced abstraction.

If you go the whole hog, and make your client leverage the full query granuality, then it also costs some FE complexity .e.g Apollo. But you dont always need that aspect.

Is this good for your problem space? Depends. Is it great for some problem spaces, 100%

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

#217

Post by virgilp »

Aeolun wrote: post #213
plif wrote: post #160

Earlier quoted context omitted.

I don't think #2 is that big of a deal if all requests happen async, which they should with a client side ORM, and if you're using http2. I think the bigger problem there is how those multiple REST calls map to your data stores. Very rarely will there be clean separation of data between endpoints, and the stateless nature of REST makes it harder to optimize each call -- meaning, there will almost certainly be redunda…

If you cache enough, your frontend dev can call as many things as they want and it will still be more or less instant.

Some people, when confronted with a performance problem, think "I know, I'll use a cache." Now they have two problems.

(in other words: caching is complicated, and may make your systems very hard to understand & debug)

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

#218

Post by Aeolun »

haimez wrote: post #137
cogman10 wrote: post #102

Earlier quoted context omitted.

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.

You cannot make a statement like that and then not provide an alternative. Personally I think dataloader makes amazing use of Javascript async.

There may be other ways to scale things out, but that doesn’t mean this one isn’t good.

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

#219

Post by Aeolun »

silisili wrote: post #92
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.

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.

Of course you can do that. But eventually keeping up with all the different fill parameters is going to catch up to you.

Besides, what do you call the parameter to fill the owner of the children? Fillchildrenowners? It’s nicer to work with if your API takes this into account.

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

#220

Post by Aeolun »

baumandm wrote: post #165
gabereiser wrote: post #150

Earlier quoted context omitted.

Same. This is why I was looking for concrete examples because the problem isn’t a graphql problem, it exists in any interface. Kinda a trick question, but it was good reading people’s reasoning ;)

I agree with GP as well, but I do think there are unique circumstances with GraphQL. One difference is that if the front-end makes N+1 REST calls, it's (hopefully) obvious to the front-end developer. It's also generally easy to map the REST requests to the database queries being made. Swap it all out for a single GraphQL query and now you have no idea how it will perform or whether it was optimized for the specific f…

Apparently you could solve this using the dataloader pattern/library.

Every layer would send off one query, unless they’re dependent on each other, but it’d be a far cry from N+1

Post reply on HN