this post was submitted on 22 Mar 2025
751 points (98.7% liked)
Programmer Humor
22153 readers
3473 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Welcome to graphQL. The REST abstraction few need, but everyone wants for some reason.
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
Funny who it's your team but they did it poorly.
The royal "my team". I'm on qa, no say in development architecture unfortunately
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.
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.