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
Currently, we have strict bounds with Polly library. For example, in the settings classes we have code like this Action<DelegateResult<HttpResponseMessage>, TimeSpan> DoNothingOnBreak, where DelegateResult is a Polly class which exposed to the end-users. We want to get rid of it in the public classes to separate library API and details of it implementation.
It gives us huge benefits:
We can replace Polly with something else without breaking changes for users.
It relaxes the requirement to have the same version of Polly in the client code and our library, which is quite important to integration.
The downside of this solution is bunch of boilerplate code for wrapping some Polly classes.
The text was updated successfully, but these errors were encountered:
Ceridan
changed the title
Make clean API for end-users without strict bound with Polly
Make clean API for end-users without strict bound to Polly
Nov 5, 2020
We have made some steps in #58 to achieve this goal. During this work we have realized that it is not so easy for now to make both clean API for the end-user and get rid of all Polly bindings in the API. Also to be honest we depends on Polly very heavily, so we decide to freeze this task for now. Maybe we will re-imagine our API later.
Milestone v2.0.0
Milestone include major changes including breaking changes.
Full list of changes:
- Fix namespace clash between Dodo.HttpClient and System.Net.Http.HttpClient (#32)
- Add OverallTimeoutPolicy (#13)
- AddDefaultPolicies is renamed to AddResiliencePolicies (#45)
- CircuitBreaker is host specific by default. Host agnostic version is removed (#44)
- HttpClientSettings is replaced with ResiliencePoliciesSettings (#38)
- Add support of Retry-After http header (#40)
- Refactor API for end-users (#51)
- Re-write README (#24)
- Add .NET 5 support (#53)
- Fix flaky test (#52)
Currently, we have strict bounds with Polly library. For example, in the settings classes we have code like this
Action<DelegateResult<HttpResponseMessage>, TimeSpan> DoNothingOnBreak
, whereDelegateResult
is a Polly class which exposed to the end-users. We want to get rid of it in the public classes to separate library API and details of it implementation.It gives us huge benefits:
The downside of this solution is bunch of boilerplate code for wrapping some Polly classes.
The text was updated successfully, but these errors were encountered: