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

[–] lud@lemm.ee 3 points 1 week ago (1 children)

Funny who it's your team but they did it poorly.

[–] Donnywholovedbowling@lemmy.world 8 points 1 week ago

The royal "my team". I'm on qa, no say in development architecture unfortunately

[–] lunarul@lemmy.world 5 points 1 week ago* (last edited 1 week 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.

[–] tiredofsametab@fedia.io 2 points 1 week ago

I looked into it once at my last company, but none of us knew it and we had a tight deadline. For our scale and usecase, it definitely seemed like needless complication for most things compared to any payoff of switching.