After 6 years, I'm over GraphQL • Hacker News Board

Re: After 6 years, I'm over GraphQL

#161

Post by jerf » Thu, May 30, 2024, 1:37 PM UTC

danielheath wrote: post #103

RHSeeger wrote: post #89

Earlier quoted context omitted.

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.

My blocker on ever using GraphQL is generally if you've got enough data to need GraphQL you're hitting a database of some kind... and I do not generally hand direct query access to any client, not even other projects within the same organization, because I've spent far too much time in my life debugging slow queries. If even the author of a system can be surprised by missing indices and other things that cause slow queries, both due to initial design and due to changes to how the database decides to do things as things scale up, how can I offload the responsibility of knowing what queries will and will not complete in a reasonable period of time to the client? They get the power to run anything they want and I get the responsibility of having to make sure it all performs and nobody on either side has a contract for what is what?

I've never gotten a good answer to that question, so I've never even considered GraphQL in such systems where it may have made sense.

I can see it in something big like Jira or GitHub to talk to itself, so the backend & frontend teams can use it to decouple a bit, and then if something goes wrong with the performance they can pick up the pieces together as still effectively one team. But if that crosses a team boundary the communication costs go much higher and I'd rather just go through the usual "let's add this to the API" discussions with a discrete ask rather than "the query we decided to run today is slow, but we may run anything else any time we feel like it and that has to be fast too".

Re: After 6 years, I'm over GraphQL

#162

Post by BiteCode_dev » Thu, May 30, 2024, 1:39 PM UTC

ctvo wrote: post #146

BiteCode_dev wrote: post #99

Earlier quoted context omitted.

React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time. I remember above all that: - React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.…

> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> c…

The simple fact you say

> React has always had good documentation

Tells me you rewrite the entire history.

In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.

At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial.

And by the way, we have been doing components for UI way before react was a thing. jQuery could do components. Backend frameworks could do components.

As for immutable data, I've seen more small projects die from the small cuts of trying to maintain that purity that I've seen those exploiting the benefits like free time travel.

I assume you've been living HN bubble for too long.

Re: After 6 years, I'm over GraphQL

#163

Post by Izkata » Thu, May 30, 2024, 1:41 PM UTC

doctor_eval wrote: post #131

dgb23 wrote: post #69

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar. Same problem with Prisma Model definitions and other such things. Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and…

What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?

From https://graphql.org/learn/queries/

This isn't even close to valid json:

  {
    empireHero: hero(episode: EMPIRE) {
      name
    }
    jediHero: hero(episode: JEDI) {
      name
    }
  }

Re: After 6 years, I'm over GraphQL

#164

Post by strken » Thu, May 30, 2024, 1:41 PM UTC

jerf wrote: post #155

strken wrote: post #121

Earlier quoted context omitted.

I'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc. If…

There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in…

Sorry, what? The original suggestion was that a developer would change things and it would cause performance problems. That same developer can change either a REST system or a GraphQL system and introduce the same performance issues in the same way, probably by adding a horrible N+1 query, or unbounded parallelism, or unbounded anything else.

Yeah, the client can't change the query if you don't let it specify a query, this is trivially true, but the developer can go break an API endpoint with the exact same result while trying to achieve the exact same business outcome.

Re: After 6 years, I'm over GraphQL

#165

Post by crabbone » Thu, May 30, 2024, 1:42 PM UTC

vitiral wrote: post #136

I've read the article and a few of the responses but have never used GraphQL. However I have a question Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc? So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.

Just use SQL? A much better language with saner semantics overall.

My first and last impression from GraphQL were that whoever wrote it hadn't had a chance to work with other query languages. A lot of the problems OP mentioned were quite on the surface. Had you ever used ORM, you'd be very intimately familiar with N+1 problem. Had you ever encountered SELinux, you'd be painstakingly familiar with authorization problems. Had you ever worked with XML (especially schemas), you'd be aware of parsing problems created by exploiting recursive properties of the grammar.

To me, GraphQL feels like a project by someone who is very enthusiastic, but lacks experience. If you need more examples of the same: the Terraform configuration language (not sure what it's called), Neo4j query language (I think it's called Cypher), libconfuse, Protobuf, and many, many more... unfortunately.

Re: After 6 years, I'm over GraphQL

#166

Post by aaronbrethorst » Thu, May 30, 2024, 1:42 PM UTC

mattbrewsbytes wrote: post #140

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…

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

Harder to get a promotion when you’re doing something that’s old, boring, and just works.

Re: After 6 years, I'm over GraphQL

#167

Post by cmgbhm » Thu, May 30, 2024, 1:43 PM UTC

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?

There’s a free query depth. There’s ways to do query cost but federating that then becomes really annoying. Coming from the security side, there’s always a long curve of explaining and an even longer curve of mitigating.

I always am happy when I get an elegant query working. Often however I just find I wasted time looking for a clean 1 query solution when iteration by caller was the only solution.

Re: After 6 years, I'm over GraphQL

#168

Post by barrkel » Thu, May 30, 2024, 1:44 PM UTC

strken wrote: post #121

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'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc. If…

If you have separation between front and back end, then the back end team can elect to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level.

Thing get more problematic when there's vertical ownership for a feature, where the UI needs just a few extra things and you end up with a REST response which is fatter and fatter, in the interest of avoiding round trips and client-side joins.

The problem with killing correct queries that take too long is that it shows up as intermittent failure that's dependent on server load and data cardinality. You might not find it in testing and it ships a bad experience to the customer before bugs are found. Whereas APIs which can't be so easily misused make it much harder to ship bugs.

Re: After 6 years, I'm over GraphQL

#169

Post by ksec » Thu, May 30, 2024, 1:45 PM UTC

>GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018.

6 years. For a lot of people, that was also the time ( 2013 - 2019 ) they moved from SPA or Client Side Rendering and started looking or move back to HTML+ approach.

So may be for any company operating on Boring Technology principle, you should not choose any hyped tech until they have been battle tested by the market for 7 years.

Re: After 6 years, I'm over GraphQL

#170

Post by jerf » Thu, May 30, 2024, 1:46 PM UTC

strken wrote: post #164

jerf wrote: post #155

Earlier quoted context omitted.

There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in…

Sorry, what? The original suggestion was that a developer would change things and it would cause performance problems. That same developer can change either a REST system or a GraphQL system and introduce the same performance issues in the same way, probably by adding a horrible N+1 query, or unbounded parallelism, or unbounded anything else. Yeah, the client can't change the query if you don't let it specify a query…

The much more constrained input of the REST query means that the effect of changes on the API are much more comprehensible. Performance testing a particular REST endpoint is generally practical, and if a dev doesn't do it, the responsibility is reasonably placed on them. GraphQL means that you may do something you think is completely innocent like changing some index but for some query you didn't anticipate it trashes the performance. The range of things the dev of a GraphQL endpoint must be keeping track of is much larger than a REST endpoint, arguably exponentially so (though generally with a low power factor in practice, the possible queries are still exponentially complicated), and taking on any form of exponential responsibility is generally something that you should do only as a last resort, even if you do think your powers will stay low.