3 ms·
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 spe
by eurasiantiger 4y ago
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?
- jdmg94 4y agoyes, everything happens over regular http(s) you can literally just 'fetch' a graphQL API
- sudowing 4y agoIndeed. 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.
- mdaniel 4y agoIsn'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 4y agoTrue, 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.