Get with the times, I get latest Erlang and Elixir literally the same day. 
Jokes aside, great library, thank you for it.
dimitarvp
derek-zhou
I noticed that it needs a cleanup process in the user’s supervision tree, so does it support multiple instances in the same VM? Consider the situation that my project depends on 2 packages and each dependency use AtomicBucket in turn. Will the cleanup processes step on each other’s toe? Usually, this is handled with a server startup parameter to silo each instance.
0
a3kov
Yes, see Server Configuration section in the README/Docs. You can simply run many server processes, 1 per table. Each server only runs 1 cleanup at a time, for its own table.
The only conflict possible is if there’s a duplicate table name. But that can happen with any library, I think. Generally as a library author in such case I would rather let my users start their own servers and ask them to provide table name in the app config.
0
derek-zhou
Thanks, it wasn’t obvious to me that one can pass :table in opts in the request/5 call to silo buckets. May I suggest you to adopt the technique similar to Ecto:
# In your application code
defmodule Sample.Repo do
use Ecto.Repo,
otp_app: :my_app,
adapter: Ecto.Adapters.Postgres
end
and inject wrapper for request/5 with table parameter set to :my_app or something more appropriate for ease of use?
1
a3kov
a3kov
Version 0.5.0 is out with major changes based on feedback from @derek-zhou and my own considerations. The bad news is that it’s breaking changes, but the good news is that overall it will help make the library better (or at least I hope it will 
):
- rate limiter modules generate own macros that replace global macros
- rate limiter options replace global macro options and server options as the main form of configuration
- each rate limiter module provides child spec for starting AtomicBucket server managing its buckets
persistentis now a parameter of rate limiter module, affecting all of its bucketsraw_requestandmulti_requestmacros are now simplyrequest- multi-bucket
detailsoption converted to a separaterequest_detailsmacro
This provides significant advantages:
- configuration compiled in for the limiter module is much less fragile than the options passed to macros before
- less options passed to macros means less code overall (DRY)
- each rate limiter has own server which can be tuned for the limiter’s bucket type
- users no longer can mix buckets of different types by mistake
- as the rate limiter now knows server parameters, it can provide even more validations at compile time - this is already in effect
- “persistent” buckets require special care and now they can be isolated in a rate limiter with completely different parameters. In the future, additional optimizations will be possible for this feature, because the server will know if it manages this type of buckets
There is also a minor speed-up in some operations due to easier access to rate limit parameters.
There is a a short instruction for the upgrade from earlier versions , but some reading of the docs may still be necessary.
2