GraphQL: The enterprise honeymoon is over • Hacker News Board

Re: GraphQL: The enterprise honeymoon is over

#161

Post by andrewingram » Mon, Dec 15, 2025, 1:57 AM UTC

jiggawatts wrote: post #84

timcobb wrote: post #22

> The main problem GraphQL tries to solve is overfetching. this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL. In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, wh…

> overfetching is never such a big problem Wait, what? Overfetching is easily one of the top #3 reasons for the enshittification on the modern web! It's one of the primary causes of incredible slowdowns we've all experienced. Just go to any slow web app, press F12 and look at the megabytes transferred on the network tab. Copy-paste all text on the screen and save it to a file. Count the kilobytes of "human readable"…

It is still a major problem, yes. Interestingly, if you go back to the talks that introduced GraphQL, much of the motivation wasn’t about solving overfetching (they kinda assumed you were already doing that because it was at the peak of mobile app wave), but solving the organisational and technical issues with existing solutions.

Re: GraphQL: The enterprise honeymoon is over

#162

Post by andrewingram » Mon, Dec 15, 2025, 1:59 AM UTC

switz wrote: post #106

rbalicki wrote: post #90

Earlier quoted context omitted.

#1 unnecessary network waterfalls #2 downloading the same fields multiple times #3 downloading unneeded data/code Checks out

Hilariously – react server components largely solves all three of these problems, but developers don't seem to want to understand how or why, or seem to suggest that they don't solve any real problems.

It’s no secret that RSC was at least partially an attempt to get close to what Relay offers but without requiring you adopt GraphQL.

Re: GraphQL: The enterprise honeymoon is over

#163

Post by andrewingram » Mon, Dec 15, 2025, 2:02 AM UTC

hirsin wrote: post #130

verdverm wrote: post #23

I have strong agreement here and would add reasoning about auth flow through nested resolvers is one of the biggest challenges because it adds so much mental overhead. The reason is that a resolver may be called through completely different contexts and you have to account for that The complexity and time lost to thinking is just not worth it, especially once you ship your GarphQL app to production, you are locking d…

Authz overhead for graphql is definitely a problem. At GitHub we're adding github app support to the enterprise account APIs, meaning introducing granular permissions for each graphql resource type. Because of the graph aspect, queries don't work til all of the underlying resources have been updated to support github apps. From a juice vs squeeze perspective it's terrible - lots of teams have to do work to update the…

I mean, the use of GraphQL for third party APIs has always been questionable wisdom. I’m about a big a GraphQL fan as it gets, but I’ve always come down on the side of being very skeptical that it’s suitable for anything beyond its primary use case — serving the needs of 1st-party UI clients.

Re: GraphQL: The enterprise honeymoon is over

#164

Post by eatsyourtacos » Mon, Dec 15, 2025, 2:08 AM UTC

cluckindan wrote: post #59

There is a pattern where GraphQL really shines: using a GraphQL native DB like Dgraph (self-hosting) and integrating other services via GraphQL Federation in a GraphQL BFF.

Sounds like a great way to completely lock yourself into an ecosystem you'll never be able to leave!

Re: GraphQL: The enterprise honeymoon is over

#165

Post by etherfirma » Mon, Dec 15, 2025, 2:13 AM UTC

I don't agree with the author on most of this. GraphQL is far better than REST in almost every way and I disagree that the server side resolvers are somehow difficult to write. In a true enterprise setting, the federation capabilities are fantastic.

There are plenty of things to dislike about GraphQL that he doesn't touch on, like: * lack of input type polymorphism * lack of support for map types * lack of support for recursive data structures (e.g., BlogComments) * terrible fragment syntax

Re: GraphQL: The enterprise honeymoon is over

#166

Post by bakugo » Mon, Dec 15, 2025, 2:23 AM UTC

0x696C6961 wrote: post #144

bakugo wrote: post #113

Earlier quoted context omitted.

This project seems to be mostly AI generated, so keep that in mind before replacing any existing solutions.

No it doesn't

Did you see the repo?

https://github.com/kubb-labs/kubb

Most of the commits and pull requests are AI. Issues are also seemingly being handled by AI with minimal human intervention.

Re: GraphQL: The enterprise honeymoon is over

#167

Post by smrtinsert » Mon, Dec 15, 2025, 2:42 AM UTC

timcobb wrote: post #22

> The main problem GraphQL tries to solve is overfetching. this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL. In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, wh…

Curious what tooling you're for graphql? Intellij has excellent support for it as does Postman.

Re: GraphQL: The enterprise honeymoon is over

#168

Post by jwaldrip » Mon, Dec 15, 2025, 2:46 AM UTC

On OpenAPI vs GraphQL: I disagree with the premise that OpenAPI achieves the same thing. GraphQL is necessarily tightly coupled to your backend — you can't design a schema that does something other than what's actually implemented. OpenAPI, on the other hand... I've seen countless implementors get it wrong. Specs drift from reality, documentation lies, and you're trusting convention. Sure, OpenAPI can do whatever you want, but for those of us who prefer convention over configuration, GraphQL's enforced contract is the whole point. On authentication concerns: Yes, auth in GraphQL has varied implementations with no open standard. But REST doesn't thrive here either... it's all bespoke. This is a tooling problem, not a GraphQL problem. Resolvers become your authorization boundary the same way endpoints with controller actions do in REST. Different shape, same responsibility. On type generation: In my experience, the codegen tooling with Apollo and Relay is incredible. I haven't seen anything on the OpenAPI side that comes close to that developer experience.

Re: GraphQL: The enterprise honeymoon is over

#169

Post by petterroea » Mon, Dec 15, 2025, 2:52 AM UTC

Another problem the article doesn't mention is how much of a hassle it is to deal with permissions. Depending on the GraphQL library you are using, sure, but my general experience with GraphQL is that the effort needed to secure a GraphQL API increases a lot the more granular permissions you need.

Then again, if you find yourself needing per-field permission checks, you probably want a separate admin API or something instead.

Re: GraphQL: The enterprise honeymoon is over

#170

Post by o1o1o1 » Mon, Dec 15, 2025, 2:56 AM UTC

jwaldrip wrote: post #168

On OpenAPI vs GraphQL: I disagree with the premise that OpenAPI achieves the same thing. GraphQL is necessarily tightly coupled to your backend — you can't design a schema that does something other than what's actually implemented. OpenAPI, on the other hand... I've seen countless implementors get it wrong. Specs drift from reality, documentation lies, and you're trusting convention. Sure, OpenAPI can do whatever you…

> Specs drift from reality

This is only an issue if the spec is maintained manually. In my opinion, best practice is to generate the specification from the actual implementation—assuming you didn’t start by hand-crafting the spec in the first place.

If the spec is the source of truth, server and client stubs can be generated from it, which should likewise prevent this kind of drift.

I realize that working with OpenAPI isn’t always straightforward, but most of the friction usually comes down to gaps in understanding or insufficient tooling for a given tech stack.