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

171–180 of 243 posts

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

#171

Post by dyeje »

valenterry wrote: post #143
dyeje wrote: post #132

Earlier quoted context omitted.

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 a specific set of data that you can optimize queries for You mean when someone creates a REST API he magically knows in advance how it will be used and writes a bunch of specific, optimized endpoints and queries such as "/magic-endpoint/" which returns 20 blogposts with their comments? I don't think so. And even if that were true, the same could easily be done with GraphQL.

It's not magic, you would design it in advance so you know what you're querying by and what you're returning in the payload. Typically you'd probably separate it into two endpoints `/blogposts` and `/blogposts/:id/comments`, but there are many ways to approach the problem. These days JSON:API is pretty popular for creating standard interfaces.

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

#172

Post by valenterry »

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…

The GraphQL equivalent to creating a new, specialized REST route would be to create a new, specialized query.

E.g. the following REST

    /articles-with-comments?number=20
which returns title, contents etc. would map to a completely new query in graphql

    articlesWithComments(number: Integer) {
      title
      contents
      ...
    }
so it is exactly as easy to optimize. Of course this is not very composable, but that is equally true for both solutions.

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

#173

Post by bryanrasmussen »

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.

I think if you have a small team and are developing an API for your application's needs probably things can be done as well or better in Rest, but if you have an API that needs to face to third parties or a very large organization with APIs that need to be exposed to multiple frontend teams or a product like a CMS that frontend teams that are not part of your organization then the benefits of GraphQL will often quickly outweigh Rest.

This is a feeling on the problem space, and not based on any studies though, as I'm unaware of any studies trying to determine this.

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

#174

Post by ako »

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.

OData (which is REST) can return the schema and much more: $metadata resource describes all entities, operations, relations, and can also contain documentation, capabilities, etc.

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

#175

Post by lmeyerov »

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.

We get that out of the box w boring old django/sqlize

we do happen to do more interesting things elsewhere (GPGPU, columnar streaming analytics, reactive frontend, ...), so like sharp edges when a 10X+ lift, but ended up backing up on this layer as it was adding complexity w immature layers vs what felt like similar perceived benefits from reliable boring stuff. it doesn't scratch all our itches, but the big ones are at a layer above/beyond graphql vs rest (eg, auth)

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

#176

Post by valenterry »

dyeje wrote: post #171
valenterry wrote: post #143

Earlier quoted context omitted.

> REST endpoints typically return a specific set of data that you can optimize queries for You mean when someone creates a REST API he magically knows in advance how it will be used and writes a bunch of specific, optimized endpoints and queries such as "/magic-endpoint/" which returns 20 blogposts with their comments? I don't think so. And even if that were true, the same could easily be done with GraphQL.

It's not magic, you would design it in advance so you know what you're querying by and what you're returning in the payload. Typically you'd probably separate it into two endpoints `/blogposts` and `/blogposts/:id/comments`, but there are many ways to approach the problem. These days JSON:API is pretty popular for creating standard interfaces.

> It's not magic, you would design it in advance so you know what you're querying by and what you're returning in the payload

Where is the difference to GraphQL then? If you know in advance what will be queried then you can create an optimized query for it.

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

#177

Post by reidrac »

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.

This was my experience as well.

Also the API provider had a "GraphQL is self-descriptive, go away" attitude when asked for documentation that made things worse.

It could be me (or my team), but we didn't find it easy at all to explore the API and find what we were looking for. We ended using a Python tool that generated some classes from the schema and, thanks to that, we managed to figure out the queries we needed to use in our Scala client. Not a fan.

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

#178

Post by matsemann »

bryanrasmussen wrote: post #173
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.

I think if you have a small team and are developing an API for your application's needs probably things can be done as well or better in Rest, but if you have an API that needs to face to third parties or a very large organization with APIs that need to be exposed to multiple frontend teams or a product like a CMS that frontend teams that are not part of your organization then the benefits of GraphQL will often quick…

I'm in the same boat. I like integrating with graphql endpoints. But for endpoints I make myself for my own frontend, I prefer making exactly what I need. Doing it more general would be a waste of time (YAGNI etc), and since it's often the critical path (not just data fetching) it's nice to have it clearly laid ot what's happening, without having to have knowledge about how the frontend happens to call it.

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

#179

Post by reidrac »

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.

I've used jsonsprc a few times and my experience was excellent (opposite to GraphQL, actually).

But the jsonrpc endpoint had good documentation and the client library didn't feel alien to the project, like a big query string embedded in the client code.

I wonder why jsonrpc is not used more often; but I guess compared to a REST API, the client may be more complicated.

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

#180

Post by watwut »

14u2c wrote: post #126
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.

There are definitely some cons, but I don't think the learning curve of the query language is one of them. It's simple enough that you can easily pick it up after 15 mins of reading the docs. There is also a schema proved by every server that tells you exactly what can be queried. This is much nicer than having to refer to documentation of unknown quality before you know what a REST api can provide. Now actually impl…

Yeah, I came to project that used graphql without even knowing what it is and I was able to write queries basically from get go.

It just was not difficult to learn at all.

Post reply on HN