7

Today our so called "architects" chose the most complicated, most unmaintainable, prehistoric way to handle a simple, really easy REST problem...they stood around the white board, marveling at the alleged brilliancy of their imbecile drawings and tried to show us low life devs how we should implement this or that idiotic aspect of their crazy solution. We looked at each other desperately, raising our eyebrows at each new wave of insanity. No one spoke up...that includes me. I feel shit right now. Implementation sprint starts tomorrow. Thinking of grabbing a life vest and jumping overboard right now. Our customer will strangle us for this wannabe crap and I am already scared having to show the resulting API to them.

Comments
  • 0
    what did they choose?
  • 2
    @mishaor well they probably wanted to start by rolling their own TCP implementations. The current ones just don’t scale
  • 4
    @mishaor it boils down to the requirement that a resource id in a GET has to be obfuscated. Salting and hashing would have done the trick but nah, they designed a dragon involving two databases, keycloak and a message queue.
  • 0
    @jaydee101 really? could've used random numbers (first is 1319310231, second is 129139123, third is 442909309, etc.) instead of ordered numbers (first resource is 1, second is 2, third is 3, you get the idea) in resource IDs, treated the ID as a hex number, and then converted it to Base64, and that's it. obfuscated and requires a few lines of code.
Add Comment