Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

101–110 of 721 posts

Re: After 6 years, I'm over GraphQL

#101

Post by tomrod »

BiteCode_dev wrote: post #92
DanielHB wrote: post #47

Earlier quoted context omitted.

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…

I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?

Re: After 6 years, I'm over GraphQL

#102

Post by serpix »

RHSeeger wrote: post #89
dudeinjapan wrote: post #57

Earlier quoted context omitted.

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller…

Then we just come back full round trip to REST where the backend clearly defines what is allowed and what is returned. So using GraphQL it is unnecessary complicated to safeguard against a caller querying for all of the data and then some. For example the caller queries nested structures ad infinitum possibly even triggering a recursive loop that wakes up somebody at 3am.

Re: After 6 years, I'm over GraphQL

#103

Post by danielheath »

RHSeeger wrote: post #89
dudeinjapan wrote: post #57

Earlier quoted context omitted.

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller…

The problem is that the client team can - without notice - change their query patterns in a way that creates excess load when deployed.

When you use the "REST" / JSON-over-HTTP pattern which was more common in 2010, changes in query patterns necessarily involve the backend team, which means they are aware of the change & have an opportunity to get ahead of any performance impact.

Re: After 6 years, I'm over GraphQL

#104

Post by pavel_lishin »

atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

We have similar issues in our codebases - but not just in GraphQL, but also in our PHP and Elixir code, and to some extent our Typescript stuff.

I think the "learning-on-the-go" symptom, where you can sometimes literally read down a file and watch some developer learn the language as they add more and more functions to the file with a gradual increase in skill (or, to put it less charitably, as they slowly get less bad at writing code) is probably a very common thing, and not just a GraphQL issue.

Re: After 6 years, I'm over GraphQL

#106

Post by BiteCode_dev »

tomrod wrote: post #101
BiteCode_dev wrote: post #92

Earlier quoted context omitted.

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…

I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?

Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away.

But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed.

And even if it's not the case, you can now break the client at any time because they decide to use a feature you gave them, but that you actually can't deal with right now.

Re: After 6 years, I'm over GraphQL

#107

Post by mst »

purge wrote: post #27

many of these concerns are mitigated by ensuring you are using trusted documents ( https://benjie.dev/graphql/trusted-documents )

Seems like at that point exposing each query as an OpenAPI endpoint would achieve pretty much the same thing.

Then again having GraphQL as the definition for them is probably still not bad, I'll just have to write something that converts them to SQL::Abstract 2 trees once I get around to porting it to TS.

Re: After 6 years, I'm over GraphQL

#108

Post by nixalon »

zer00eyz wrote: post #2

GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…

[flagged]

Re: After 6 years, I'm over GraphQL

#109

Post by nesarkvechnep »

DanielHB wrote: post #53
9dev wrote: post #34

Earlier quoted context omitted.

What is that you find so complex about RESTful APIs?

Pure REST API is a huge pain in the ass to use and leads to bad performance because of waterfall requests. It is like the number one thing GraphQL solves for most people, decide which nested relationships to inline into a response. The simplicity makes it bad to use, if you work around the simplicity (arbitrary inlining, extra fields to choose what to inline, etc) then you end up with non-standard complexity.

Bad performance if you haven’t heard about HTTP caching. REST implies cacheabality.

Re: After 6 years, I'm over GraphQL

#110

Post by nprateem »

I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project.

In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

Post reply on HN