-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/retry and ratelimit #38
base: main
Are you sure you want to change the base?
Conversation
I'd love your thoughts on this @FuzzyStatic. I was sitting and writing wrappers for blizzard client methods in my project and figured it would probably be of value to this lib |
@roffe I'm a little wary about adding new dependencies. This package aims to be simple enough for anyone to use. That being said, if this package is going to add these new parameters, defaults should always be used unless otherwise specified by the end-user. To clean this up the NewClient function should ingest a new structure called For rate-limiting and retrying, these options should default to not being used unless there is clear user-defined input, or in the case of Blizzard's own rate limit, a documented default constant value. If you can get this PR up to the above requirements, then I can look into merging this PR into the codebase. Does that seem fair? |
The reason to why I added a variadic input to the end of NewClient was to not break backwards compatibility Do you mean the new way to create a client would look something like this?: config := &blizzard.Config{
ClientID: "my id",
ClientSecret: "my secret",
Region: blizzard.EU,
Locale: blizzard.EnUS,
HttpClient: &http.Client{
// ... opts
},
}
blizz := blizzzard.NewClient(config)
https://develop.battle.net/documentation/guides/game-data-apis
I picked 3 as a default value with a exponential back-off for the retry, so if it was 100ms first, it's 200 second and 400ms wait the 3rd time I'll think about how to implement retry without using 3rd party libs, is x/retry still ok? Edit 1: |
Yes, this is what I meant. For the rate limiter, if there is a As for the retry, I'd still prefer the retry default be no retry unless parameters are specified in the config. I don't feel it's necessary to create your own retry implementation, avast is fine. |
Adds retry logic in case of 429 as well as ratelimit with sane defaults for the Battle.net API configurable via optional opts on the client to not break backwards compatibility
usage example to configure custom, shown with default values:
also I snuck in a http.Client config with keep-alive, should increase performance for people who use it in backends and system service doing a lot of lookups in a row