31–40 of 241 posts
https://www.gqlstandards.org/ is an ISO standard. The Graph Database people don't love search engine results when they're looking for something.
I maintain a graph database where support for GQL often comes up.
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…
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…
I think you're oversimplifying it. You've left on the part where the client can specify which fields they want.
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…
> 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…
Not sure about the schema evolution part. Protobufs seem to work great for that.
Do we think this has turned out to hold? Is caching an API http response of no value in 2025.
> 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.
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.
> 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…