> This is not an issue from my point of view. If you do GraphQL the right way you'll always use persisted Queries.
But that's not using GraphQL "the right way", is it?
I mean, GraphQL's value proposition is quite literally letting front-end developers run all sorts of ad-hoc queries without having to bother about indexes, and only care about the data you wish to extract.
If all you want is to run fixed queries then you're already better off putting up a REST API.
Facebook, the inventors of GraphQL, didn't just invent the language itself. At the same time they invented the Relay client. This client, back then, persisted all Queries at compile time. They never had actual Queries at runtime. It's Apollo with their Apollo client who made it popular to not follow this path. The devs at Facebook never said you must use GraphQL their way but I think if you don't follow their best practices you're kind of on your own. Why not follow their advice? They must have learned this lesson already.
Front end developers are api consumers in the same way that a third party client is.
As others have stated persistent queries are the answer. You can disable them in local dev if you want to give your devs more flexibility, but I have found it usually isn't necessary.
But that's not using GraphQL "the right way", is it?
I mean, GraphQL's value proposition is quite literally letting front-end developers run all sorts of ad-hoc queries without having to bother about indexes, and only care about the data you wish to extract.
If all you want is to run fixed queries then you're already better off putting up a REST API.