• (nodebb)

    This is an API that's so flexible that it forgot to make the common use cases accessible to most developers.

    A common problem, both in "for others to use" APIs and "for us to use" internal APIs.

    The stupidest part is that it would just require a single function that called all that mess and returned the result, so that the behaviour is the same everywhere it's needed. If you want something more or less different, then sure, call the detailed mess that's needed, but if it really is, exactly as written, a common use case, the API providers should have provided it as well.

    The big problem is the quantity of cargo-cultist developers out there who would call that function and then do some deep-juju handwaving to adapt the result to their specific needs that were, in the end, exactly the same as the common use case anyway, because ===> that dude over there did it for some case that actually was different.

  • (nodebb)

    "Do not molly coddle your users - give them one way to accomplish a goal" ... Excellent advice (nominally) 30 years ago and still true today.

    YES, the order matters in a set of fall back strategies. The provided code is a SAMPLE of one possible order. Any individual use-case may want more or less or different orders. Only the customer (aka developer of application) knows what they want. The vendor can not possibly guess right.

  • Cody (unregistered)

    If anyone guessed the major cloud vendor here was named after a large river, you get a cookie.

    In their defence, I believe that's from v2 of their PHP SDK, which itself was a fairly thin wrapper around v3 of the open source Guzzle library, which...yeah, had some pretty terrible design decisions. On the other hand, Guzzle v3 was deprecated and abandoned in 2014, and v3 of the cloud vendors PHP SDK came out in 2015, and newer versions of Guzzle (and the vendor's SDK) are much better.

    Also despite what the writeup says, I don't think anything quite that ugly is in the official docs, and if you're consuming the API you're mostly expected to call provided factory methods that set all that up for you. So as Steve says, it would just require a single function that called all that mess and returned the result, and in fact, that's what the vendor in question did.

    So that's a contrived example in 8 year old code. Still ugly though.

  • (nodebb)

    Obligatory note: TRWTF is always PHP.

  • MaxiTB (unregistered)

    Well, that's an interesting case of dependency injection done in reverse :-)

  • Tim (unregistered)

    As would be immediately apparent to anyone who knows the slightest thing about design patterns, the solution to this problem would be some kind of AbstractBackoffStrategyFactory object

  • Red Five (unregistered)

    There were enough closing parens there that I thought this was Scheme instead of PHP.

  • JC (unregistered)

    If you throw a well designed builder pattern in the mix, most of the ugliness should go away. Although, it requires taste and good documentation.

  • Not Enough (unregistered)

    Needs a few more layers! I'm livin' the 10X lifestyle!

  • Your Name (unregistered) in reply to JC

    Yeah, keep piling turd over turd with lots of patterns, strategies and factories, so that in the end the code looks almost like the plain four lines as before, just with additional 20 classes to accomodate "I'vE UsEd LoTs Of DeSiGn PaTtErNs".

    Keep the code maintainable. If you can't see which actual classes are used on a glance it is not.

    Dependency injection needs to die in a fire. What's so bad about Instance = new Class() that you need to hide it?

  • Jeremy (unregistered)

    They should aim to have a strategy ready before pageload I think. Have they thought about using a default strategy of 3 retries on responses 5xx?

    I love that they do want to retry on 509 'Bandwith limit exceeded'

  • pif (unregistered)

    This is an API that's so flexible that it forgot to make the common use cases accessible to most developers.

    When did RTFM stop being excellent advice?

  • clubs21ids (unregistered)
    Comment held for moderation.
  • Barf4Eva (unregistered) in reply to Your Name

    It doesn't need to die in a fire. It just needs to be kept simple whenever possible, such as just basic object registrations, and exposed only where it makes sense to make for more flexible code. One can do all of this using "Poor Man's DI" with simple classes that do just as you describe and then simply handle the instantiations for the interfaces yourself against concrete types. But then you don't have a nice central place for that kind of plumbing like you do w/ a DI container. And why write the code in the first place, if you have no need? Not to mention it tends to be baked in to a lot of frameworks these days so that it exposes itself nicely, especially when building an MVC .Net 5 app or something of the sort. The flexibility to inject in my needs to controllers is quite nice.

Leave a comment on “Hey, Backoff!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article