4 ms·

I've had the "pleasure" of using the predecessor of this library at work. The code written by someone who's just completed reading the GoF book feels remarkabl

• jondot 14y ago
  From the 10 minutes I glanced at the code I kinda got lost in the abstractions and that's where I decided it's worth a deep look later, but I wouldn't say it's over-engineered. Can you elaborate a bit?
  • elq 14y ago
    my problem with this library (well, actually the internal version, I haven't looked much at the code in github) is that it was written from the perspective of an edge service - the netflix API. The needs of that system are quite different from the needs of middle-tier systems. The API has a hell of a lot more surface area but is trivial in complexity compared other systems at netflix, and therefor this library has some huge gaps in design. The two biggest issues IMHO are putting the throttling/fallback handling at the outermost edge of an external service rather than at the lowest level (i.e. the actual rpc) and a very C/errno like method of handling errors. I'm also quite unhappy with the API. It require creating boilerplate classes to implement the commands. Yuck. A bit of magic with annotations or code gen would've been much cleaner and much less prone to errors caused by programmer fatigue or boredom.
    • jondot 14y ago
      Thanks
    • quotemstr 14y ago
      Thanks - you expressed the uneasy feeling I had more eloquently than I could have. Between the library's architecture, the (IMHO) architectural inversion, and the (let's be honest) stilted writing style in the documentation, this project gives me an "I'm just out of college" feeling, which in turn usually makes me run like hell.