GraphQL is trendy, but unless you need to maintain a lot of different versions of your API it doesn't really seem worth the investment.
REST vs. GraphQL – A search for evidence on which is better
111–120 of 243 posts
Re: REST vs. GraphQL – A search for evidence on which is better
#112Earlier quoted context omitted.
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.
Well, I would argue with "true" REST, all of your REST routes are specific, and generally therefore easy to optimize.
Re: REST vs. GraphQL – A search for evidence on which is better
#113Earlier quoted context omitted.
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…
In my experience, N+1 queries are roughly as easy to run into with naive GraphQL as with naive REST. When you are optimizing the queries, it's slightly easier to get rid of the N+1 behavior in GraphQL than in REST because you can see exactly what data the client is trying to get and can fetch data differently based on that instead of needing to come up with your own way for the API to describe what data to fetch.
> In my experience, N+1 queries are roughly as easy to run into with naive GraphQL as with naive REST.
We're currently dealing with this on a REST API right now. If you have highly relational data, you run N+1 risks regardless. I think people misplace blame on REST/GraphQL when they will have fundamental data issues either way.
We're exploring a few ways of solving it, but they honestly all resemble GraphQL.
Re: REST vs. GraphQL – A search for evidence on which is better
#114Earlier quoted context omitted.
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
Hasura generates one SQL query per top-level field. Hasura takes advantage of Postgres's JSON features to compile a deeply-nested graphql query into a single query.
It's pretty impressive too. For any deeply-nested query, like fetching the 1-to-many children of 1-to-many children of some entity, a lot of ORMs will often have to resort to doing N+1 queries, which adds a surprising amount of latency to a request.
Re: REST vs. GraphQL – A search for evidence on which is better
#115Serious question: given how difficult correctly parsing SELECT commands (and avoiding SQLi and other horrible issues like db parser impl bugs) is, why hasn't someone implemented a db whose query language is graphQL?
There's some activity in this space.
Hasura uses a GraphQL-SQL compiler to generate Postgres SQL queries directly from a graphql query: https://hasura.io/
FaunaDB, EdgeDB and DGraph are examples of databases that expose a GraphQL API.
Re: REST vs. GraphQL – A search for evidence on which is better
#116I have never implemented GraphQL, so I can't speak from experience, there, but it does look pretty cool (if a bit "heavy").
I have implemented REST. I don't like "pure" REST, where POST, PATCH, and PUT statements are submitted as XML and/or JSON.
I tend to do what I term "REST-like," sort of the way most APIs seem to do, these days, where the sending methods are done similar to standard URI GET/POST stuff (URI arguments).
I tend to have responses come back as both JSON and XML, with a translator between them. XML is useful, because I can publish a schema, but otherwise, I prefer JSON.
But REST-like is quite simple. I don't need to bring in any dependencies to provide the API, so it's fast and lightweight.
But then, I have fairly humble servers. I suspect that GraphQL would be something I'd want for more ambitious servers.
Re: REST vs. GraphQL – A search for evidence on which is better
#117This is comically meaningless as far as evidence for making a decision goes. It reminds me of the various garbage studies purporting to show that functional programming leads to lower defect rates.
Re: REST vs. GraphQL – A search for evidence on which is better
#118A 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?
I think he is saying graphql doesn't have recursion.
Re: REST vs. GraphQL – A search for evidence on which is better
#119I'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.
At work almost every endpoint supports an “expand” parameter that will do various expansions of referenced resources in the returned records. This can:
- cause additional sql joins - or pull individual records from a cache (if it’s a small enough dataset) - or cause one additional DB query and save a network round trip.
Example:
/api/v2/discussions?sort=recent&expand=insertUser,updateUser,lastCommentUser,parentCategory
This would be a pretty extensive case but is very useful.
Re: REST vs. GraphQL – A search for evidence on which is better
#120Earlier quoted context omitted.
I just looked at Categories list there at https://42papers.com/categories and WOW is it broken. Examples: Social and Information Networks category description is: Covers all aspects of computing with sound, and sound as an information channel. Includes models of sound But over in Audio and Speech Processing the description says: General methodological and applied contributions to economics.
The categories are from ARXIV this is how they have defined stuff. I'm working on adding our own tag layer on top. https://arxiv.org/category_taxonomy
Whatever you're using to transform the arxiv taxonomy, it's wildly mixing up the category names and descriptions.