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

GraphQL: The enterprise honeymoon is over

johnjames.blog

Post reply on HN
Print view View original

51–60 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#51

Post by spooneybarger »

aabhay wrote: post #41

How do GraphQL based systems solve the problem of underlying database thrashing, hot shards, ballooning inner joins, and other standard database issues? What prevents a client from writing some adversarial-level cursed query that causes massive internal state buildup? I’m not a database neckbeard but I’ve always been confused how GraphQL doesn’t require throwing all systems knowledge about databases out the window

Most servers implement a heuristic for "query cost/complexity" with a configurable max. At the time the query is parsed, its cost is determined based on the heuristic and if it is over the max, the query is rejected.

Re: GraphQL: The enterprise honeymoon is over

#52

Post by thom »

jayd16 wrote: post #24
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…

This seems a bit reductive as it skims over the whole query resolution part entirely.

This, for me, is a perfect description of the entirety of GraphQL tbh.

Re: GraphQL: The enterprise honeymoon is over

#53

Post by akio »

If all your experience comes from Apollo Client and Apollo Server, as the author's does, then your opinion is more about Apollo than it is about GraphQL.

You should be using Relay[0] or Isograph[1] on the frontend, and Pothos[2] on the backend (if using Node), to truly experience the benefits of GraphQL.

[0]: https://relay.dev/

[1]: https://isograph.dev/

[2]: https://pothos-graphql.dev/

Re: GraphQL: The enterprise honeymoon is over

#54

Post by hdjrudni »

verdverm wrote: post #33
8n4vidtmkvmk wrote: post #32

Earlier quoted context omitted.

I think you're oversimplifying it. You've left on the part where the client can specify which fields they want.

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

Sure, maybe you compile away the query for production but the server still needs to handle all the permutations.

Re: GraphQL: The enterprise honeymoon is over

#55

Post by hdjrudni »

FootballMuse wrote: post #37
8n4vidtmkvmk wrote: post #35

Earlier quoted context omitted.

Pruning the request and even the response is pretty trivial with zod. I wouldn't onboard GQL for that alone. Not sure about the schema evolution part. Protobufs seem to work great for that.

Pruning a response does nothing since everything still goes across the network

Pruning the response would help validate your response schema is correct and that is delivering what was promised.

But you're right, if you have version skew and the client is expecting something else then it's not much help.

You could do it client-side so that if the server adds an optional field the client would immediately prune it off. If it removes a field, it could fill it with a default. At a certain point too much skew will still break something, but that's probably what you want anyway.

Re: GraphQL: The enterprise honeymoon is over

#56

Post by Culonavirus »

trashymctrash wrote: post #16

What I liked about GraphQL was the fact that I only have to add a field in one place (where it belongs in the schema) and then any client can just query it. No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“. It just cuts that discussion short. I also really liked that you can create a snapshot of the whole schema for integra…

> No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“.

Do people actually work like this is 2025? I mean sure, I guess when you're having entire teams just for frontends and backends then yea, but your average corporate web app development? It's all full stack these days. It's often expected that you can handle both worlds (client and server) and increasingly its even TypeScript "shared universe" when you don't even leave the TS ecosystem (React w/ something like RR plus TS BFF w/ SQL). This last point, where frontend and backend meet, is clearly the way things are going in general. I mean these days React doesn't even beat around the bush and literally tells you to install it with a framework, no more create-react-app, server side rendering is a staple now and server side components are going to be a core concept of React within a few years tops.

Javascript has conquered the client side of the internet, but not the server side. Typescript is going to unify the two.

Re: GraphQL: The enterprise honeymoon is over

#57

Post by Dibes »

hashmap wrote: post #45

> GraphQL isn’t bad. It’s just niche. And you probably don’t need it. > Especially if your architecture already solved the problem it was designed for. What I need is to not want to fall over dead. REST makes me want to fall over dead. > error handling is harder than it needs to be GraphQL error responses are… weird. > Simple errors are easier to reason about than elegant ones. Is this a common sentiment? Looking at…

If isomorphic TS is your cup of tea, tRPC is a nicer version of client server contracting than graphql in my opinion. Both serve that problem quite well though.

Re: GraphQL: The enterprise honeymoon is over

#58

Post by verdverm »

hdjrudni wrote: post #54
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

Sure, maybe you compile away the query for production but the server still needs to handle all the permutations.

yup, and while they are fixed, it amounts to a more complicated code flow to reason about compared to you're typical REST handler

Seriously though, you can pretty much map GraphQL queries and resolvers onto JSONSchema and functions however you like. Resolvers are conceptually close to calling a function in a REST handler with more overhead

I suspect the companies that see ROI from GraphQL would have found it with many other options, and it was more likely about rolling out a standard way of doing things

Re: GraphQL: The enterprise honeymoon is over

#60

Post by fgkramer »

verdverm wrote: post #33
8n4vidtmkvmk wrote: post #32

Earlier quoted context omitted.

I think you're oversimplifying it. You've left on the part where the client can specify which fields they want.

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

Post reply on HN