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
I'd like to look at enabling different rate limiting strategies in a way that they can be shared across all stores rather than needing store-specific logic. It'd be good to be able to implement strategies such as sliding window, and leaky bucket/token bucket, bursts, etc once and then have it automatically be supported by any store.
This would also include things like a passOnStoreFailure option that would allow the limiter to "fail open".
I think this means we need to make some changes to the store API, such as being able to set the expiry time, and potentially being able to grab and sum multiple keys at once.
I'd like to keep the store interface fairly simple, but also leave room for backend-specific optimizations, and I'm not yet sure what the right balance is there.
Maybe we have a fairly generic store interface, and express-rate-limit includes strategies that use the generic interface, but then stores can override specific strategies with ones that use private methods for better efficiency. I'm a little fuzzy on the details, though.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'd like to look at enabling different rate limiting strategies in a way that they can be shared across all stores rather than needing store-specific logic. It'd be good to be able to implement strategies such as sliding window, and leaky bucket/token bucket, bursts, etc once and then have it automatically be supported by any store.
This would also include things like a
passOnStoreFailure
option that would allow the limiter to "fail open".I think this means we need to make some changes to the store API, such as being able to set the expiry time, and potentially being able to grab and sum multiple keys at once.
I'd like to keep the store interface fairly simple, but also leave room for backend-specific optimizations, and I'm not yet sure what the right balance is there.
Maybe we have a fairly generic store interface, and express-rate-limit includes strategies that use the generic interface, but then stores can override specific strategies with ones that use private methods for better efficiency. I'm a little fuzzy on the details, though.
See also:
passOnConnectionError
option rate-limit-redis#193Beta Was this translation helpful? Give feedback.
All reactions