4 ms·

i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af142956acc9 https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14

by fcpguru 10mo ago

i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af142956acc9 https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint

gideon60 10mo ago
Feels like a schema design issue? If your REST backend exposes a single path to remove an item, are there any reason why your GraphQL schema doesn't expose a root mutation field taking the same arguments?
- fcpguru 10mo ago
  yeah tell shopify, it's their api!
  - johnjames4214 10mo ago
    Exactly. If it's that verbose and painful for a public API like Shopify/GitHub (where the 'flexibility' argument is strongest), it makes even less sense for internal enterprise apps. We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.
    - n_e 10mo ago
      The issue is that the API itself is, I assume, badly designed. Equivalent delete queries in rest / graphql would be curl -X DELETE 'https://api.example.com/users/123' vs curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'
throwaway613745 10mo ago
wut we have a mixed graphql/REST api at $DAY_JOB and our delete mutations look almost identical to our REST DELETE endpoints. TFA complains needing to define types (lol), but if you're doing REST endpoints you should be writing some kind of API specification for it (swagger?). So ultimately there isn't much of a difference. However, having your types directly on your schema is nicer than just bolting on a fragile openapi spec that will quickly become outdated when a dev forgets to update it when a parameter is added/removed/changed.
- ashishb 10mo ago
  Generate the open API spec from the backend for internal applications. No need to update manually. Further, you can prevent breaking changes to the spec using oasdiff
roscue 10mo ago
I feel you. But I think this might have more to do with the cursed design of the Shopify order editing API than with GraphQL itself.

by fcpguru 10mo ago

gideon60 10mo ago

Feels like a schema design issue? If your REST backend exposes a single path to remove an item, are there any reason why your GraphQL schema doesn't expose a root mutation field taking the same arguments?

fcpguru 10mo ago
yeah tell shopify, it's their api!
- johnjames4214 10mo ago
  Exactly. If it's that verbose and painful for a public API like Shopify/GitHub (where the 'flexibility' argument is strongest), it makes even less sense for internal enterprise apps. We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.
  - n_e 10mo ago
    The issue is that the API itself is, I assume, badly designed. Equivalent delete queries in rest / graphql would be curl -X DELETE 'https://api.example.com/users/123' vs curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'

throwaway613745 10mo ago

wut we have a mixed graphql/REST api at $DAY_JOB and our delete mutations look almost identical to our REST DELETE endpoints. TFA complains needing to define types (lol), but if you're doing REST endpoints you should be writing some kind of API specification for it (swagger?). So ultimately there isn't much of a difference. However, having your types directly on your schema is nicer than just bolting on a fragile openapi spec that will quickly become outdated when a dev forgets to update it when a parameter is added/removed/changed.

ashishb 10mo ago
Generate the open API spec from the backend for internal applications. No need to update manually. Further, you can prevent breaking changes to the spec using oasdiff

roscue 10mo ago

I feel you. But I think this might have more to do with the cursed design of the Shopify order editing API than with GraphQL itself.