Skip to content
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

Ideas for improving resiliency of the client #296

Open
robrap opened this issue Sep 13, 2023 · 3 comments
Open

Ideas for improving resiliency of the client #296

robrap opened this issue Sep 13, 2023 · 3 comments

Comments

@robrap
Copy link
Contributor

robrap commented Sep 13, 2023

It seems like it would be useful for the client to have additional resiliency capabilities such as retries, exponential backoff, auto-handling of rate limiting, circuit breaker, etc. that would both protect the caller and callee, both of which would be useful to prevent common situations where services fall like dominoes (e.g. Discovery, then LMS).

Each idea could be ticketed separately.

@robrap
Copy link
Contributor Author

robrap commented Sep 13, 2023

@johnnagro: Did you say there is enterprise code that might be lifted for some of this?

@robrap robrap added this to Arch-BOM Sep 13, 2023
@robrap
Copy link
Contributor Author

robrap commented Sep 19, 2023

[inform] From DRF throttling docs:

If the .wait() method is implemented and the request is throttled, then a Retry-After header will be included in the response.

It's unclear to if a custom throttle is required to get this behavior. However, it is possible, and would allow clients to call as efficiently as possible when throttled.

@robrap
Copy link
Contributor Author

robrap commented Sep 19, 2023

Clients should be using timeouts. See docstring. Do we need to improve docs (move from README to how-to?) and/or add linting? See README docs.

@jristau1984 jristau1984 moved this to Backlog in Arch-BOM Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant