[wasyl]

I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions. Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL queries makes little sense. But for internal APIs, whitelisting whatever queries current clients need isn't any less convenient

[joegibbs]

I might be thinking about this the wrong way, but with GraphQL you're writing a query (in the GraphQL syntax) on the frontend which gets whatever data the frontend needs for whatever it's doing, and that query is interpreted by the backend to fetch specific data. But if you're whitelisting specific queries, which has to be done on the backend, what if you just move the queries themselves to the backend, and call them from the frontend by specific names for shorthand? And then from there, what if you refactored it so that each "query" was just a function with an associated endpoint?

[nfw2]

You would have a more permissive development environment where all queries are permitted. Then, once the change to FE code and related queries are finalized, you could automatically have the production whitelist updated before the FE is deployed to prod.