111–120 of 241 posts
Earlier quoted context omitted.
If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.
Graphql solves the problem. There is no problem here for openapi to solve. See how that works?
But the point is that that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql over something else.
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…
But the first point is also its demise. I have object A, and want to know something from a related object E. Since I can ask for A-B-C-D-E myself, I just do it, even though the performance or spaghettiness takes a hit. Then ends up with frontend that's tightly coupled to the representation at the time as well, when "in the context of A I also need to know E" could've been a specialized type hiding those details.
GraphQL clients are built to do exactly that, Relay originally and Apollo in the last year, if I’m understanding what you’re saying: any component that touches E doesn’t have to care about how you got to it, fragment masking makes short work
Earlier quoted context omitted.
Discovering Kubb was a game changer for me last year.
Thanks for mentioning this. I always find it unsettling when I've researched solutions for something and only find a better option from a random HN comment. Site: https://kubb.dev/
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/
One interesting conjecture that GQL makes, I think, is that idempotent request caching at the http level is dead... Or at least can't be a load bearing assumption because the downstream can change their query to fetch differently. Do we think this has turned out to hold? Is caching an API http response of no value in 2025.
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
My experience with GraphQL in a nutshell: A lot of effort and complexity to support open ended queries which we then immediately disallow and replace with a fixed set of queries that could have been written as their own endpoints.
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.
What else does relay give me that URQL does not?
GraphQL was created to solve many different problems, not just overfetching. These problemes at the time generally were: 1) Overfetching (yes) from the client from monolithic REST APIs, where you get the full response payload or nothing, even when you only want one field 2) The ability to define what to fetch from the CLIENT side, which is arguably much better since the client knows what it needs, the server does not…
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 (cl…
Full stack is common for simple web apps, where the backend is almost a thin layer over the database.
But a lot of the products I’ve worked with have had backends that are far more complex than something you could expect the front end devs to just jump into and modify.
Earlier quoted context omitted.
Graphql solves the problem. There is no problem here for openapi to solve. See how that works?
Openapi is older than graphql. But the point is that that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql over something else.