4 ms·

"... rough edges ... complex" I've put a couple GraphQL services into production and have similar thoughts. What suprised me most were the range of views from

"... rough edges ... complex" I've put a couple GraphQL services into production and have similar thoughts. What suprised me most were the range of views from colleagues when they needed to integrate into one of their products. Some people were happy to work with something new, while others didn't appreciate the tax involved with the learning curve. That said, I published an app that auto-provisions a CRUD service in GraphQL. So while I may not use it for most apps, I use this for general data-access. https://github.com/sudowing/service-engine-template https://github.com/sudowing/service-engine-template

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 ago
  yes, everything happens over regular http(s) you can literally just 'fetch' a graphQL API
- sudowing 4y ago
  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.
- mdaniel 4y ago
  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 4y ago
    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.

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 ago
yes, everything happens over regular http(s) you can literally just 'fetch' a graphQL API
sudowing 4y ago
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.
mdaniel 4y ago
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 4y ago
  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.