gideon60 2 days 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?

Reply View 3 replies
  • fcpguru 2 days ago

    yeah tell shopify, it's their api!

    Reply View 2 replies
    • johnjames4214 2 days 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.

      Reply View 1 reply
      • n_e 2 days 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 } }'
        Reply View 0 replies
throwaway613745 2 days 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.

Reply View 1 reply
  • ashishb 2 days 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

    Reply View 0 replies
roscue 2 days 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.

Reply View 0 replies