You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using FailSafe is a useful solution. In some cases, we'd like to keep the option to adapt / change the policy or its parameters (e.g. number of retries, timeouts) on the fly. That could be for debugging purposes or in need to react to an external event. With failsafe, these changes require a code update and a deployment of the file.
We'd like to suggest an integration from FailSafe to Lunar Proxy in order to allow the developer to delegate some decisions to Lunar or to allow Lunar to add on top of the resilience measures defined by FailSafe - e.g. changing the fallback values without code redeployment.
We saw a case where a similar change was required for multiple uses / deployments of code that used FailSafe. We'd like to allow the developer to plan (in advance) cases / API calls which leave more flexibility instead of coding the strategy & its parameters.
Also adding as a reference: #320 (the option for a backend was mentioned there)
The text was updated successfully, but these errors were encountered:
Using FailSafe is a useful solution. In some cases, we'd like to keep the option to adapt / change the policy or its parameters (e.g. number of retries, timeouts) on the fly. That could be for debugging purposes or in need to react to an external event. With failsafe, these changes require a code update and a deployment of the file.
We'd like to suggest an integration from FailSafe to Lunar Proxy in order to allow the developer to delegate some decisions to Lunar or to allow Lunar to add on top of the resilience measures defined by FailSafe - e.g. changing the fallback values without code redeployment.
This can be done with Lunar, an API egress proxy - https://github.com/TheLunarCompany/lunar (an Open Source project under MIT license)
We saw a case where a similar change was required for multiple uses / deployments of code that used FailSafe. We'd like to allow the developer to plan (in advance) cases / API calls which leave more flexibility instead of coding the strategy & its parameters.
Also adding as a reference: #320 (the option for a backend was mentioned there)
The text was updated successfully, but these errors were encountered: