| ▲ | timcobb 2 days 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | JAlexoid a day ago | parent | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
> 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? | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | rbalicki 2 days ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
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 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 a day ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
URQL and gql.tada are great client side tooling innovations. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | smrtinsert a day ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
Curious what tooling you're for graphql? Intellij has excellent support for it as does Postman. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | jiggawatts 2 days ago | parent | prev [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
> 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! | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||