Interesting that GraphQL consumers would see it as excessively taxing. Did you mention that GraphQL APIs can be queried with plain HTTP requests without any specific GraphQL client?
curl https://example.com/some/endpoint?someq=yup
curl -d '{"query":"query Q { someMethod(someArg: \"someValue\") { ...ohgawd } }"}' https://example.com/graphql
And, from the JS PoV, similar burden of the "interior" language
fetch("https://example.com/graphql", {method: "POST", body: "query Q { #and the rest }"})Besides, any sane developer will build an abstraction on top of the fetch request.
The difference to any other JSON reply is minimal.
But once other teams started integrating -- we heard all kinds of feedback.
My thoughts afterward were simply that people under the time pressure to push features daily had different appetites for any friction in their workflow.
We considered the feedback from the larger team and intentionally added support for both REST & GraphQL in our next app. We wanted to support anyone that wanted some exposure to it without forcing anyone. And that had much better feedback from consumers.