Episode 13 - Two rate limiting strategies Monday, 11 Dec.
Last Monday I introduced the following issue:
If your stream is created from key presses or mouse movements, you’ll likely deal with bursts of events. But you can’t react to every single event, as it would overload the CPU or flood the servers with too many requests.
I presented the
❚ debounceTime card. It rate-limits events, based on an “emission silence” window of time. Learn more about it in Episode 12.
Today, we explore another rate-limiting strategy with the
❚ throttleTime card. Like
❚ debounceTime, it accepts a time period argument. But
❚ throttleTime doesn’t delay events:
▬ number piece on
❚ throttleTime to set a time period, such as
500 milliseconds. Then, this is how
❚ throttleTime operates:
- It starts by emitting the first event of the input stream
- Then, it limits the rate of events to at most one per time period
- As a result, it returns a new stream of “throttled” events
❚ debounceTime and
❚ throttleTime both accept a time period and rate limit the emissions of the input stream. But as you can see on the visualization above, they operate in a very different way. Take some time considering both options for your next project!