"Better" is only meaningful in context.

GraphQL is only "WAY better" if you make a number of important design decisions (and assumptions) that I as a realist, pragmatist, and application architect with 25+ years of experience am simply unwilling to make.

In reality, GraphQL is a solution in search of a problem. If you're doing REST correctly, designing correctly for things like pagination of large data sets, and (far more importantly) if you're your entity modeling correctly and consistently caching the results of your REST operations, GraphQL is entirely redundant while adding unjustified complexity and cost to the stack.

In other words, it's yet another Band-Aid fix for shoddy engineering practices. Focus on the fundamentals. There are no "sprinkle on" solutions. Quality must be "baked in". A little GraphQL fairy dust isn't going to solve a badly designed or implemented system.

And it's not free. All that querying, filtering, and assembling query results has a real cost.

Remember when the last batch of 20-somethings tried to tell us that document databases were "way better" than relational databases? But then they realized that to get good and necessary things like referential integrity, someone had to hand code, debug, test, and optimize what's been built into relational engines for almost half a century now?

Yeah.

I have no doubt that GraphQL will find adherents. And a market. And an ecosystem of pricey tooling to support it. But none of that means it's necessary or even a good idea.

Hard pass, until I see a problem that my technical designs don't already resolve.