[eurasiantiger]

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?

[mdaniel]

Isn't that only true if the consumer is fluent in GraphQL syntax?

  curl https://example.com/some/endpoint?someq=yup

versus

  curl -d '{"query":"query Q { someMethod(someArg: \"someValue\") { ...ohgawd } }"}' https://example.com/graphql

even typing that out I had to carefully count back the closing braces

And, from the JS PoV, similar burden of the "interior" language

  fetch("https://example.com/graphql", {method: "POST", body: "query Q { #and the rest }"})

[eurasiantiger]

True, a query is needed, but that is pretty straightforward and crucially, there are schema-aware editors that just plug in to the endpoint. Boom, autocomplete for fields and queries, and syntax validation out of the box. Indispensable piece of any GraphQL backend stack.

Besides, any sane developer will build an abstraction on top of the fetch request.

The difference to any other JSON reply is minimal.

[sudowing]

Indeed. Thats actually how my team's FE engineers called our API.

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.

[jdmg94]

yes, everything happens over regular http(s) you can literally just 'fetch' a graphQL API