Why not?
Why not?
Secondly, it may just be something solved as the tech becomes more mature and practiced, but there are numerous smaller issues such as versioning (the ability to change rapidly without breaking backward compatibility is separate from when you DO want to break that compatibility) and tooling. These are hardly solved issues with, say REST, but they are "more solved". Most places have some level of versioning, and requests are trivial to read with existing tooling.
When doing an involved front end app (I was in ag tech working on app that was tying data models with farm field overlay maps and setting values by geographic region - which sounds way more impressive than it really is) I found that GraphQL seemed great for straightforward CRUD apps, where the results of a query and the display of the page mapped closely, but the value add on the front end was pretty minimal for more complex applications. Lots of tooling (Apollo at the time, and I hear "Relay" being discussed today) performs magic to make this all effortless.
"magic" is great when it works - we adopt it and stop considering it magic. The other times it is usually a flash in the pan that spawns lots of regrets. I'd be an idiot to claim I knew which side of magic this falls on, but my experience is currently saying to avoid anything too involved. A GraphQL API? Sure, it's not my first pick but I'll use it. A framework that magically hides all the complexity on the front end? I'm willing to bet I'll run afoul of some hidden boundary.
If I'm at a company that starts talking GraphQL I'd ask about the solutions for caching and versioning. If they have answers, I'll keep listening. If they wave it off as something to worry about later, I'd expect headaches.
A long, rambling, and subjective answer, but that's my answer.
I use this in prod, and the only downside I'm aware of is the length limit on the query string. (Haven't hit it though)
https://stackoverflow.com/questions/2659952/maximum-length-o...