• Donnywholovedbowling@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      3 days ago

      My team recently migrated to graphql and they don’t even do it right. The graphql layer still makes REST calls and then translates them to a gql format, so not only do we get no time or computing savings, we also get the bullshit errors

    • lunarul@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      3 days ago

      It make sense for a wrapper layer to do this and I had to fight against APIs that didn’t. If I make a single HTTP call that wraps multiple independent API calls into one, then the overall HTTP code should reflect status of the wrapper service, and the individual responses should each have their own code as returned by the underlying services.

      For example on one app we needed to get user names by user id for a bunch of users. To optimize this, we batched calls into groups. The API would fail with an error code if one of the user ids in the batch was bad or couldn’t be found. That meant we wouldn’t be getting data for any of the users in the batch and we didn’t know which userId was bad either. Such a call should return 200 for the overall call and individual result for each id, some of which could be errors.