ExHammer/hammer

Hammer is an Elixir library that provides configurable rate-limiting capabilities for applications. It supports multiple backends, including ETS, atomic operations, and Redis, and implements various algorithms such as fixed window, sliding window, token bucket, and leaky bucket. The system offers a macro-based API for defining custom rate limiters and includes an automated installation task to integrate the service into an application's supervision tree.

6 changes.

The project underwent a significant architectural overhaul, replacing the legacy module interface with a new macro-based API for defining rate limiters. This period introduced modern atomic and ETS backends supporting multiple algorithms, while simultaneously upgrading the Elixir version and removing obsolete configuration and application modules.

8 changes.

This period focused on introducing a high-performance atomic backend for rate limiting, implementing algorithms like Token Bucket and Leaky Bucket with race-condition-safe concurrency. It also added comprehensive test coverage for both ETS and atomic backends and introduced a new mix task to automate the setup of rate limiters.

The repository has been initialized with standard Elixir project configuration files, including \.credo.exs\ for code linting, \.formatter.exs\ for code formatting, \.editorconfig\ for editor consistency, and \.tool-versions\ pinning Elixir 1.20.4 and Erlang 29.0.5. Comprehensive documentation has been added, including a detailed \README.md\ describing the Hammer rate-limiter library, its backends (ETS, Atomic, Redis, Mnesia), algorithms, and installation via Igniter, alongside \CHANGELOG.md\, \BENCHMARKS.md\, \CONTRIBUTING.md\, \CODE\_OF\_CONDUCT.md\, and \LICENSE.md\.

(repo-wide) · high confidence

This release adds five new rate-limiting algorithm implementations for the ETS backend, giving users more granular control over traffic shaping. The \:fix\_window\ algorithm provides simple, wall-clock-aligned windows, while \:fix\_window\_per\_key\ anchors windows to each key's first hit to prevent globally synchronized burst boundaries. The \:sliding\_window\ algorithm offers precise enforcement by tracking individual request timestamps, eliminating boundary bursts at the cost of higher storage. Additionally, \:token\_bucket\ and \:leaky\_bucket\ algorithms are introduced to support burst tolerance and smooth, constant-rate limiting respectively, with configurable refill rates, capacities, and costs.

lib/hammer/ets · high confidence

Users can now run \mix hammer.install\ to automatically generate a rate limiter module (e.g., \MyApp.RateLimit\) and add it to the application supervision tree. The task supports selecting a backend via the \--backend\ flag (defaulting to \ets\, with \atomic\ and \redis\ options), and requires the Igniter tool to be installed. When using the \redis\ backend, it also adds the \hammer\_backend\_redis\ dependency and configures the child spec with a default Redis URL.

lib/mix · high confidence

The Hammer library now provides two distinct backend implementations for rate limiting: an atomic backend using Erlang's :atomics module (requiring OTP 21.2+) and an ETS-based backend. Both backends support multiple algorithms including :fix\_window, :fix\_window\_per\_key, :sliding\_window, :leaky\_bucket, and :token\_bucket, allowing users to choose the strategy that best fits their concurrency and burst requirements. A new \:before\_clean\ callback option is available on both backends, enabling users to execute custom logic (such as telemetry emission) on expired entries before they are deleted. The legacy \Hammer.Application\ module has been removed, reflecting a shift in how the backend supervisors are started.

lib/hammer · high confidence

This change introduces three new ETS-backed rate-limiting implementations in the \lib/hammer/atomic\ directory: \TokenBucket\, \LeakyBucket\, and \FixWindow\ (along with a \FixWindowPerKey\ variant). These modules provide high-performance, race-condition-safe rate limiting using Erlang's \:atomics\ module for concurrent counter updates. Users can now configure their rate limiters to use \backend: :atomic\ with \algorithm: :token\_bucket\, \:leaky\_bucket\, or \:fix\_window\ to benefit from atomic operations and reduced locking overhead compared to previous backends.

lib/hammer/atomic · high confidence

The benchmark script now includes performance comparisons for Hammer's new atomic backend alongside the existing ETS backend. Specifically, it adds benchmarks for fix\_window, token\_bucket, and leaky\_bucket algorithms using the atomic backend, allowing users to evaluate the performance characteristics of atomic rate limiting against the previous ETS-based implementations.

bench · high confidence

The Hammer library has replaced its previous module interface with a new \use Hammer\ macro, allowing users to define custom rate limiter modules by specifying a backend (such as \:ets\ or \:atomic\). This change introduces a standardized callback interface for rate limiting operations (including \hit\, \inc\, \set\, \get\, and \expires\_at\) and automatically configures the chosen backend at compile time, simplifying the setup process for rate-limited applications.

lib · high confidence

The \config/config.exs\ file has been deleted, removing the previous Mix.Config-based application configuration. This change eliminates the ability to configure the application via the legacy configuration module and suggests a shift towards alternative configuration methods, such as environment variables or direct code defaults, as the standard Mix.Config import mechanism is no longer present.

config · high confidence

Added comprehensive test coverage for ETS and Atomic backends; Added test coverage for atomic and ETS backend key types; Added test coverage for the atomic backend's rate-limiting algorithms; Added test helpers for bucket expiry and callback verification; Added tests for the mix hammer.install Igniter task.

The project has been upgraded to require Elixir 1.14 (previously 1.4) and bumped the application version to 7.5.0. Development dependencies have been updated, including credo to 1.7.19, ex\_doc to 0.40.4, dialyxir to 1.4.8, and igniter to 0.8.4. The project structure has also been modernized to use the Mix.Project DSL, adding configuration for documentation, package metadata, and dialyzer PLT settings.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 61 → 68 (+7.3)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 98 → 99 (+0.7)
• Architecture 100 → 100 (+0.0)
• Maturity 52 → 53 (+0.6)
• Readiness 64 → 80 (+16.0)
• Security 56 → 74 (+17.9)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (10 lines × 2) (lib/hammer/atomic/leaky_bucket.ex)
• Duplicated block (20 lines × 2) (lib/hammer/atomic.ex)
• Duplicated block (5 lines × 2) (lib/hammer/atomic.ex)
• Duplicated block (5 lines × 2) (lib/hammer/ets/leaky_bucket.ex)
• Duplicated block (5 lines × 2) (lib/hammer/ets/leaky_bucket.ex)
• Duplicated block (8 lines × 2) (lib/hammer/atomic/fix_window.ex)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Off-boarding risk: anonymized user #1
• Test reliability not included
• The 'Available Algorithms:' table lists only FixWindow/Atomic/FixWindowPerKey/LeakyBucket/TokenBucket, then clips before the full list of algorithms (Sliding Window, Fixed Window) is shown and the comparison section begins. (README.md)

• Documentation: no architecture or design documentation (README.md)
• Duplicated block (10 lines × 2) (lib/hammer/atomic/leaky_bucket.ex)
• Duplicated block (11 lines × 2) (lib/hammer/atomic/leaky_bucket.ex)
• Duplicated block (23 lines × 2) (lib/hammer/atomic.ex)
• Duplicated block (8 lines × 2) (lib/hammer/ets/leaky_bucket.ex)
• Duplicated block (9 lines × 2) (lib/hammer/atomic/fix_window.ex)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Off-boarding risk: anonymized user #1
• Repeated repair: lib/hammer/ets/token_bucket.ex (lib/hammer/ets/token_bucket.ex)
• TodoComment (bench/base.exs)

• 16 commits — 12 feature/other, 4 fixes

• (root) — 10 commits
• .github/workflows — 3 commits
• lib/hammer — 2 commits
• guides/Tutorial.md — 1 commit

• fix: fix(atomic): initialize bucket atomics before publishing them in ETS (#202)
• fix: fix(ets): carry the sub-token refill remainder across hits (#197)
• fix: fix(ets): return the real time-to-next-token on token bucket deny (#198)
• fix: fix(ets): use millisecond resolution for token bucket refill (#193)
• change: Bump actions/cache from 5 to 6 (#191)
• change: Bump actions/checkout from 6 to 7 (#190)
• change: build(deps): bump dialyxir 1.4.7 -> 1.4.8 (#204)
• change: build(deps): bump erlex 0.2.8 -> 0.2.9 and add :mix to dialyzer PLT (#196)
• change: build(deps): bump igniter 0.8.0 -> 0.8.3 and dev deps (#195)
• change: build(deps): bump igniter 0.8.3 -> 0.8.4 (#205)
• change: build(deps): bump mint (security), ex_doc, spitfire (#203)
• change: build(deps): bump mint (security), sourceror, spitfire (#206)
• change: chore: Release 7.5.0 (#200)
• change: chore: pin dev toolchain to Elixir 1.20.4 / OTP 29.0.5 (#199)
• change: ci: test Elixir 1.17+ only and drop EOL OTP 26 from the matrix (#201)
• change: feat: add mix hammer.install Igniter task (#194)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ExHammer/hammer was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.