GraphQL: The enterprise honeymoon is over • Hacker News Board

Re: GraphQL: The enterprise honeymoon is over

#81

Post by andrewingram » Sun, Dec 14, 2025, 9:05 PM UTC

gavinray wrote: post #17

I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library. The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not. Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> Resul…

As someone who’s used GraphQL since mid-2015, if you haven’t used GraphQL with Relay you probably haven’t experienced GraphQL in a way that truly exploits its strengths.

I say probably because in the last ~year Apollo shipped functionality (fragment masking) that brings it closer.

I stand by my oft-repeated statement that I don’t use Relay because I need a React GraphQL client, I use GraphQL because I really want to use Relay.

The irony is that I have a lot of grievances about Relay, it’s just that even with 10 years of alternatives, I still keep coming back to it.

Re: GraphQL: The enterprise honeymoon is over

#82

Post by verdverm » Sun, Dec 14, 2025, 9:07 PM UTC

fgkramer wrote: post #60

verdverm wrote: post #33

Earlier quoted context omitted.

That's something you should only really do in development, and then cement for production. Having open queries where an attacker can find interesting resolver interactions in production is asking for trouble

But has this been thoroughly documented and are there solid libraries to achieve this? My understanding is that this is not part of the spec and that the only way to achieve this is to sign/hash documents on clients and server to check for correctness

Well, it seems that the Apollo way of doing it now, via their paid GraphOS, is backwards of what I learned 8 years ago (there is always more than one way to do things in CS).

At build time, the server generates a random string resolver names that map onto queries, 1-1, fixed, because we know exactly what we need when we are shipping to production.

Clients can only call those random strings with some parameters, the graph is now locked down and the production server only responds to the random string resolver names

Flexibility in dev, restricted in prod

Re: GraphQL: The enterprise honeymoon is over

#83

Post by lateforwork » Sun, Dec 14, 2025, 9:10 PM UTC

c-hendricks wrote: post #75

lateforwork wrote: post #70

Earlier quoted context omitted.

OpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.

And the fetching in a single request?

The question I answered was regarding contracts. Fetching in a single request can be handled by your BFF.

Re: GraphQL: The enterprise honeymoon is over

#84

Post by jiggawatts » Sun, Dec 14, 2025, 9:13 PM 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…

> 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" text, and then divide by the megabytes over the wire to work out the efficiency. For notoriously slow web apps, this is often 0.5% or worse, even if filtering down to API requests only!

Re: GraphQL: The enterprise honeymoon is over

#85

Post by lateforwork » Sun, Dec 14, 2025, 9:14 PM UTC

be_erik wrote: post #38

The appeal of GraphQL is that it eliminates the need for a BFF and easily solves service meshing. Over fetching is more of a component design problem than a performance issue.

> eliminates the need for a BFF

Does it really? What if you need to store user preferences?

Also, some would say BFF is easier to implement than GraphQL.

Re: GraphQL: The enterprise honeymoon is over

#86

Post by rbalicki » Sun, Dec 14, 2025, 9:25 PM UTC

The author is missing the #1 benefit of GraphQL: the ability to compose (the data for) your UI from smaller parts.

This is not surprising: Apollo only recently added support for data masking and fragment colocation, but it has been a feature of Relay for eternity.

See https://www.youtube.com/watch?v=lhVGdErZuN4 for the benefits of this approach:

- you can make changes to subcomponents without worrying about affecting the behavior of any other subcomponent,

- the query is auto-generated based on the fragment, so you don't have to worry that removing a field (if you stop using it one subcomponent) will accidentally break another subcomponent

In the author's case, they (either) don't care about overfetching (i.e. they avoid removing fields from the GraphQL query), or they're at a scale where only a small number of engineers touch the codebase. (But imagine a shared component, like a user avatar. Imagine it stopped using the email field. How many BFFs would have to be modified to stop fetching the email field? And how much research must go into determining whether any other reachable subcomponent used that email field?)

If moving fast without overhead isn't a priority (or you're not at the scale where it is a problem), or you're not using a tool that leverages GraphQL to enable this speed, then indeed, GraphQL seems like a bad investment! Because it is!

Re: GraphQL: The enterprise honeymoon is over

#87

Post by roscue » Sun, Dec 14, 2025, 9:29 PM UTC

I would agree that REST beats GraphQL in most cases regarding complexity, development time, security, and maintainability if the backend and frontend are developed within the same organization.

However, I think GraphQL really shines when the backend and frontend are developed by different organizations.

I can only speak from my experience with Shopify's GraphQL APIs. From a client-side development perspective, being able to navigate and use the extensive and (admittedly sometimes over-)complex Shopify APIs through GraphQL schemas and having everything correctly typed on the client side is a godsend.

Just imagining offering the same amount of functionality for a multitude of clients through a REST API seems painful.

Re: GraphQL: The enterprise honeymoon is over

#88

Post by rbalicki » Sun, Dec 14, 2025, 9:31 PM UTC

nisalperi wrote: post #13

My hot take is that if you’re using GraphQL without Relay, you’re probably not using it to its full potential. I’ve used both Relay and Apollo Client on production, and the difference is stark when the app grows!

1000%. There's almost no reason to use GraphQL unless you take advantage of data masking + fragment colocation.

Re: GraphQL: The enterprise honeymoon is over

#89

Post by rbalicki » Sun, Dec 14, 2025, 9:34 PM 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…

If you're interested in an example of really good tooling and DevEx for GraphQL, then may I shamelessly promote this video in which I demonstrate the Isograph VSCode extension: https://www.youtube.com/watch?v=6tNWbVOjpQw

TLDR, you get nice features like: if the field you're selecting doesn't exist, the extension will create the field for you (as a client field.) And your entire app is built of client fields that reference each other and eventually bottom out at server fields.

Re: GraphQL: The enterprise honeymoon is over

#90

Post by rbalicki » Sun, Dec 14, 2025, 9:35 PM 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"…

#1 unnecessary network waterfalls

#2 downloading the same fields multiple times

#3 downloading unneeded data/code

Checks out