Circuit Breaking in Node
I have been toying around in Node recently, and I have to say it has come a long way. I wanted to share with you guys a new package I published (my first npm package). Circuit breaking in Node is a popular concept as it enables a high degree of resilience. There were plenty of packages available, but none of them had some additional features, much like the php package I published.
https://github.com/geggleto/circuit-breaker-js is available through npm as geggleto-circuit-breaker.
When I was making the package I was totally surprised at the ease of its usage. The callback nature of Node.JS made writing this package super easy. The unit tests cover nearly 100% of the source code, and the unit tests are very detailed.
Let's talk about the example on the README as there is a lot going on in the background.
The breaker try method expects a boolean function which it uses to register a success or fail. That means it's up to your service to gracefully handle all errors and return a simple true/false to weather it succeeded or not. I choose this pattern just because it's pretty easy to return true/false and I really didn't care WHY things failed or HOW things failed, I just want to know that they are failing. You should have other logging as to the why's and how's inside your application. The breaker just needs to stop spamming services that are unavailable and also notify you that they did in fact fail.
What most circuit-breaker packages don't include is the option for a callback to execute the moment a service fails. I call these Tripped Handlers, because the breaker goes from closed to open, and it's at that point I need to worry about something. DevOps needs to be notified that X service has failed, and I provide that ability with the Tripped Handlers.
In the package you can specify a timeout period [retry threshold] for how long the app should wait before allowing one instance to retry the service. If that attempt fails, the service goes back to unavailable and another retry is scheduled. You will need to find a balance with this number, once the service comes back there is an obvious lag delay between that event happening and your application noticing. Another detail to consider is that after every attempted your tripped handler will execute notifying you that the service is still out.
More to come on Application Resilience
Happy Coding o7