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

91–100 of 243 posts

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

#91

Post by 5Qn8mNbc2FNCiVV »

mumblemumble wrote: post #86
jensneuse wrote: post #72

Earlier quoted context omitted.

What would you say are the hard things about GraphQL?

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 thing that I usually do is work tightly with the frontend and extract out all queries that I would be sending to my backend and whitelist only those.

F.e. when we knew that we are going to have a big spike because of a feature in the news, we checked the cost of our queries and heavily optimized and added a cache just for those queries that are costing us the most in front of our backend (based on the query string). This enabled us scaling up from 2000 concurrent users to half a million (the difference is only that big because we were super badly unoptimized before and also the near infinite limit of Cloudflare workers)

It's definitely harder when you have bigger different teams interacting with a single central GraphQL api. My rule for that is that there needs to be a gateway that handles exactly that for every service/team/whatever. Not custom coded by every team because this 100% gets mismanaged. Instead it should be just a container image managed by the same team that handles the GraphQL api and configured by the consuming team via an env var or a file containing all the queries needed.

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

#92

Post by silisili »

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.

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

#93

Post by 5Qn8mNbc2FNCiVV »

chris_st wrote: post #16
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

Try looking at the generated sql. Afaik it's (almost) always a single sql query being ran

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

#94

Post by valenterry »

Marinlemaignan wrote: post #58
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.

Agreed with this, you definitely don't want to be the one implementing it on the backend it is no fun at all and can be quite tricky with all the n+1 you didnt see coming and all that.

The n+1 would be there with REST too. Unless you have specific, optimized REST routes - but then you can do the same with specific, optimized graphQL queries too.

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

#95

Post by jayd16 »

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 without those services having to change. Imagine being able to merge a vendor API that can provide a tracking number with FedEx's API, for example.

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

#96

Post by xupybd »

altrunox wrote: post #66

A while ago I decided to build another one of those Hacker News clone, and decided to use GraphQL, everything was fine, until I got at the comments... You cannot ask for all the children of a main comment or a thread, something like "give me all the comments and sub comments of thread X" is impossible, I was quite shocked because I read nowhere about this limitation, I solved it adding an extra field to my response a…

Could you elaborate please. I don't understand the issue surely you could model this on the backend and serve it via GraphQl?

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

#97

Post by valenterry »

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…

This problem exists in REST APIs in the exact same way though, unless you specifically optimize for this way of querying. But then you can do the same thing with GraphQL, so in the end GraphQL is not worse off, actually rather better because at least the problem exists only between backend and database, not between frontend and backend and database.

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

#98

Post by xupybd »

ehutch79 wrote: post #12

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.

Try Hasura. If you have a database centric architecture you get most of the heavy lifting done for you.

Slap in keycloack and you have auth sorted.

It doesn't do everything but it's a good way to play with GraphQL

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

#99

Post by latte »

GraphQL specifies schema and documentation, and implementations usually come with introspection tools, which is not the case for REST. It would be more fair to compare GraphQL to something like Swagger.

That said, GraphQL libraries and tooling tend to be less fragmented and more ready to use than for equivalent REST stacks, which makes development much easier. A simple API built in Python with Graphene looks terse and declarative, while doing the same with Django REST Framework requires adding pages of plumbing code to build an equivalent REST API.

Re: GraphQL being a pain for a backend development - I don't quite understand that argument. If you want to keep a tighter control over the schema, you can have it - the API schema does not need to be a reflection of the underlying data schema with all its relationships - it should be the front-end developer's job to convince you that this or that complex relationship needs to be exposed via GraphQL and let you make sure that it's served efficiently.

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

#100

Post by bitL »

I always think about GraphQL as pushing versioning into the future when it's either:

1) the product is dead

2) original folks moved on

3) "it's no longer my problem"

The if-then-else spaghetti code it creates on the back-end whenever an API breaking change is needed is always cute.

Post reply on HN