Hacker News Reader

Comment by fcpguru | Hacker News Reader

i wrote this a few weeks ago:

https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14...

400 lines of QL vs one rest DELETE / endpoint

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?

yeah tell shopify, it's their api!

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.

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'

  curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'

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.

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.

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

Reply on news.ycombinator.com