Add support for multiple throttling strategies #623
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
I have a job that processes imports. During the import process I'd like to broadcast refreshes to communicate how he import is progressing - stuff like the number of created records, encountered errors, etc.
With the default debounce logic, if the import is updated too frequently, no refresh broadcast will go out until the import is done.
I can manually broadcast refreshes and throttle them to work around this issue, but it would be nice if Turbo Rails offered alternative broadcast throttling strategies like rate limiting or leading-edge debouncing.
Detail
In this PR I've exposed options on
broadcasts_refreshes
andbroadcasts_refreshes_to
through which you can change the broadcast throttling strategy.I've kept the debouncer as the default strategy as it makes the most sense for most applications.
In addition to the debouncer I've added a rate limiter strategy which allows only a set number of broadcasts in a given interval.
For convenience, if you just want to use the defaults, I've also added a short-hand definition syntax
This interface also allows you to reconfigure the debouncer's default delay of 0.5 sec
In my case, I'd prefere to keep the debounce throttler for requests to my server but would like to switch to the rate limiter when in a background job. For this I've added a
Turbo.with_throttler
method that changes the default throttler for any code executed within a block passed to it.Additional information
To make this work I had to change
ThreadDebouncer
, and in the process I've also renamed it toThreadThrottler
to better communicate its new responsibilities. This might be considered a breaking change to the public interface.It's possible to define and use custom throttlers