4 ms·

> 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

by timcobb 10mo ago

> 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, while GraphQL does this in the client. I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either. In my opinion, GraphQL tooling never panned out enough to make GraphQL worthwhile. Hasura is very cool, but on the client side, there's not much going on... and now with AI programming you can just have your data layers generated bespoke for every application, so there's really no point to GraphQL anymore.

jiggawatts 10mo ago
> 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!
- rbalicki 10mo ago
  #1 unnecessary network waterfalls #2 downloading the same fields multiple times #3 downloading unneeded data/code Checks out
  - switz 10mo ago
    Hilariously – react server components largely solves all three of these problems, but developers don't seem to want to understand how or why, or seem to suggest that they don't solve any real problems.
    - presentation 10mo ago
      I agree though worth noting that data loader patterns in most pre-RSC react meta frameworks + other frameworks also solve for most of these problems without the complexity of RSC. But RSC has many benefits beyond simplifying and optimizing data fetching that it’s too bad HN commenters hate it (and anything frontend related whatsoever) so much.
    - andrewingram 10mo ago
      It’s no secret that RSC was at least partially an attempt to get close to what Relay offers but without requiring you adopt GraphQL.
    - rbalicki 10mo ago
      There's an informed critique of RSC, but no one is making it.
- andrewingram 10mo ago
  It is still a major problem, yes. Interestingly, if you go back to the talks that introduced GraphQL, much of the motivation wasn’t about solving overfetching (they kinda assumed you were already doing that because it was at the peak of mobile app wave), but solving the organisational and technical issues with existing solutions.
- gherkinnn 10mo ago
  Overfetching does not lead to those megabytes. And it has nothing to do with the enshittification process of a middleman like Amazon fucking over both customers and sellers.
rbalicki 10mo ago
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 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.
tcoff91 10mo ago
URQL and gql.tada are great client side tooling innovations.
smrtinsert 10mo ago
Curious what tooling you're for graphql? Intellij has excellent support for it as does Postman.
JAlexoid 10mo ago
> I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either. How is this easier or faster than writing a few lines of code at BFF?

by timcobb 10mo ago

jiggawatts 10mo ago

> 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!

rbalicki 10mo ago
#1 unnecessary network waterfalls #2 downloading the same fields multiple times #3 downloading unneeded data/code Checks out
- switz 10mo ago
  Hilariously – react server components largely solves all three of these problems, but developers don't seem to want to understand how or why, or seem to suggest that they don't solve any real problems.
  - presentation 10mo ago
    I agree though worth noting that data loader patterns in most pre-RSC react meta frameworks + other frameworks also solve for most of these problems without the complexity of RSC. But RSC has many benefits beyond simplifying and optimizing data fetching that it’s too bad HN commenters hate it (and anything frontend related whatsoever) so much.
  - andrewingram 10mo ago
    It’s no secret that RSC was at least partially an attempt to get close to what Relay offers but without requiring you adopt GraphQL.
  - rbalicki 10mo ago
    There's an informed critique of RSC, but no one is making it.
andrewingram 10mo ago
It is still a major problem, yes. Interestingly, if you go back to the talks that introduced GraphQL, much of the motivation wasn’t about solving overfetching (they kinda assumed you were already doing that because it was at the peak of mobile app wave), but solving the organisational and technical issues with existing solutions.
gherkinnn 10mo ago
Overfetching does not lead to those megabytes. And it has nothing to do with the enshittification process of a middleman like Amazon fucking over both customers and sellers.

rbalicki 10mo ago

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 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.

tcoff91 10mo ago

URQL and gql.tada are great client side tooling innovations.

smrtinsert 10mo ago

Curious what tooling you're for graphql? Intellij has excellent support for it as does Postman.

JAlexoid 10mo ago

> I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either. How is this easier or faster than writing a few lines of code at BFF?