| Hey HN! I extracted BreakerMachines from my apps after seeing people dealing with cascading failures in production Rails apps. Key features that set it apart: - True async/fiber support (works with Falcon, async gems) - Built-in fallback mechanism with chaining - Thread-safe without dangerous Timeout.timeout - Memory-efficient with WeakRef tracking - Rich introspection and monitoring hooks - Clean DSL that works with inheritance With everyone adding AI/LLM APIs to their apps, circuit breakers are more critical than ever. These APIs can be slow, flaky, or have outages - without protection, your app goes down with them. The README shows patterns for graceful degradation when a service is down. I explicitly avoided shipping Redis/DB adapters to keep it focused, the README shows how to implement your own in ~20 lines. Would love feedback on the API design and any edge cases I might have missed! I'm still going to add the parallel feature, i removed it because i need to test it in CI. |
I'd suggest to drop the DSL, at the end of the day, a good old class with a constructor stored in a constant is much more more transparent:
Just my 2 cents though.