41–50 of 241 posts
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
Same I thought about nest.js, Angular.
All of them hard to understand by heart at beginning, later (a few years), you feel it and get value.
Sounds stupid, but I tried to reimplement all the benefits using class transformers, zod, custom validators, all others packages. And always end up: “alright, graphql does this out of the box”.
REST is nice, same as express.js if you create non-production code. Reality is you need to love this boilerplate. AI writes this anyway.
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
I hated GraphQL and all the hype around it. Until I finally got how to use it what for. Same I thought about nest.js, Angular. All of them hard to understand by heart at beginning, later (a few years), you feel it and get value. Sounds stupid, but I tried to reimplement all the benefits using class transformers, zod, custom validators, all others packages. And always end up: “alright, graphql does this out of the box…
> 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 a garbled mash of linux or whatever tells me a lot more than "500 sorry"
I'm only trying out GraphQL for the first time right now cause I'm new with frontend stuff, but from life on the backend having a whole class of problems, where you can have the server and client agree on what to ask for and what you'll get, be compiled away is so nice. I don't actually know if there's something better than GraphQL for that, but I wish when people wrote blogs like this they'd fill them with more "try these things instead for that problem" than simply "this thing isn't as good as you think it is you probably don't need it".
A blog post about GraphQL in an enterprise setting, that fails to address the biggest GQL feature for enterprises. Not unlike most material on HN about microservices. Federated supergraph is the killer feature imo.
The author states that in their experience, most downstream services are REST, so adding a GQL aggregation layer on top isn't very helpful. It seems possible they would have a different opinion if they were working with multiple services that all implemented GQL schemas.
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
It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).
> The main problem GraphQL tries to solve is overfetching. My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me. TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is muc…
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.
I agree with that, and when I'm in a "typescript only" ecosystem, I've switched to primarily using tRPC vs. GraphQL.
Still, I think people tend to underestimate the value of having such clear contracts and guarantees that GraphQL enforces (not to mention it's whole ecosystem of tools), completely outside of any code you have to write. Yes, you can do your own zod validation, but in a large team as an API evolves and people come and go, having hard, unbreakable lines in the sand (vs. something you have to roll your own, or which is done by convention) is important IMO.