I was looking for a well made and reusable "retry" library, but all I could find were libraries with awkward interfaces/APIs, overuses of state/pointers, a lack of extensibility, or they'd somehow opinionate themselves towards a specific purpose (HTTP retry libraries are in a major abundance).
So, I figured I'd take a stab at creating a retry library that worked in a simple loop with functional composition that would allow for easy extensibility. I ended up writing an API that somewhat heavily used the functional option pattern described so well by Dave Cheney in his blog post: "Functional options for friendly APIs" (http://dave.cheney.net/2014/10/17/functional-options-for-fri...).
Ideally, the library's packages can be used separately, so you could use the `jitter` transformations even if you don't want to use the actual `retry` mechanism. That is why the library is split into a few packages.
Anyway, I'm curious as to what HN thinks about this library. Anything that I could definitely improve? Is there anything awkward about the API in particular? Something that I missed?
Rican7|9 years ago
So, I figured I'd take a stab at creating a retry library that worked in a simple loop with functional composition that would allow for easy extensibility. I ended up writing an API that somewhat heavily used the functional option pattern described so well by Dave Cheney in his blog post: "Functional options for friendly APIs" (http://dave.cheney.net/2014/10/17/functional-options-for-fri...).
Ideally, the library's packages can be used separately, so you could use the `jitter` transformations even if you don't want to use the actual `retry` mechanism. That is why the library is split into a few packages.
Anyway, I'm curious as to what HN thinks about this library. Anything that I could definitely improve? Is there anything awkward about the API in particular? Something that I missed?
I appreciate the feedback! Thanks!