kefyusuf/laravel-bloom-gate
Laravel Bloom Gate adds Bloom filter-backed gates to Laravel, providing fast, memory-efficient authorization checks that plug into the framework's Gate system. Guard routes and actions with a lightweight probabilistic access-control layer.
Laravel Bloom Gate v0.1.0-rc.2 is an evaluation release candidate for a Laravel/PHP query-avoidance layer using Bloom filters to reduce absent-value SQL lookups. The architectural fit is narrow but potentially valuable: applications with a high ratio of negative lookups against SQL-backed data may benefit from reducing database calls, but the release explicitly states this is workload-dependent and not evidence of general latency improvement. In the local 1,000-query absent-value workload, SQL queries fell from 1,000 to 8, while the Redis gate was slower than indexed local MySQL, PostgreSQL, and in-memory SQLite baselines. All-present workloads avoided no SQL calls.
Integration is feasible for teams on PHP 8.3+ and Laravel 12/13 using the documented installation path: require the exact 0.1.0-rc.2 package and publish the config. The package supports trusted negatives with a production-only Redis plus MySQL, PostgreSQL, or SQLite consumers according to the candidate tests, but this is not production certification. The README now includes an executable immutable filter example and distinguishes legacy pre-add from coordinated prepared writes, which helps reduce integration ambiguity. However, coordinated mutable filters require every membership-entry writer to participate in the prepared-write protocol.
Technical risk is material for a TPM to manage. This is not a stable v1 release and not a production deployment certification. Redis Cluster, unobserved production deployments, long-running retained history, and MongoDB integration are not certified. Redis trusted negatives require the documented durable standalone-primary profile. SQL comparison/collation must agree with the filter’s normalization semantics. Writer drain now rejects inconsistent surviving lease/count evidence in Memory and Redis without repairing it, so operational failures may surface rather than self-heal.
Key questions for TPM review:
Stack fit should be validated against the exact runtime constraints: PHP 8.3+, Laravel 12/13, a supported SQL consumer, and Redis only under the documented standalone-primary profile for trusted negatives. The package is not a general-purpose performance enhancement; it is a targeted optimization for absent-value query patterns. TPM should require a measured baseline of the target application’s datastore behavior and negative-query ratio before approving any performance objective.
Migration should begin with a non-production pilot, not a broad rollout. The candidate pilot installs the exact selected source commit and emits bounded query and retained-lease measurements, which is the right pattern for evaluation. Teams should validate trusted negatives, authoritative fallback, known SQL commit/rollback outcomes, and rebuild behavior in an environment that mirrors production datastore and Redis topology. Packagist registration, indexing, and remote installation must be observed separately from the GitHub tag; installation should be pinned to 0.1.0-rc.2 and verified through the closure record.
Compatibility risks are explicit: Redis Cluster is not certified, MongoDB is unverified, long-running retained history is not certified, and unobserved production deployments are out of scope. SQL comparison/collation must agree with normalization semantics, so PostgreSQL, MySQL, and SQLite should be tested with the application’s actual collation and normalization rules. Immutable filter usage is simpler and should be preferred unless coordinated mutable writes are genuinely required.
Sequencing recommendation:
Maintenance burden includes monitoring retained lease history and writer drain validation. The release notes report local writer drain median growth from about 0.16–0.20 ms with no retained leases to 2.33–2.86 ms with 1,000 released leases. These are bounded development measurements, not production throughput limits, but they indicate that retained history should be monitored and bounded in production-like pilots. Inconsistent surviving lease/count evidence is rejected rather than repaired, so operators need a recovery runbook backed by authoritative evidence.
Support expectations should be set conservatively. This is an evaluation release candidate, not a stable v1 or production certification. The package owner’s long-term support posture, upgrade path, and production-readiness criteria should be confirmed before adoption. Packagist availability should be verified independently from the GitHub tag, and deployments should pin the candidate version.
Scaling risk is workload- and topology-dependent. Redis trusted negatives require the documented durable standalone-primary profile; Redis Cluster is not certified. The Redis gate was slower than indexed local SQL baselines in the reported workload, so the optimization should be justified by SQL query avoidance rather than assumed latency gains. All-present queries avoided no SQL calls, meaning low-negative-ratio workloads may see operational overhead without benefit. Long-running retained history and unobserved production deployments are explicitly outside certification.
Primary failure modes to plan for:
Ramp-up should include Bloom filter semantics, immutable versus coordinated mutable filter usage, prepared-write protocol obligations, fallback and rebuild procedures, retained-lease monitoring, and the distinction between query avoidance and latency improvement. A TPM should treat v0.1.0-rc.2 as a controlled evaluation candidate and require pilot evidence, observability, and a documented support path before any production commitment.
How can I help you explore Laravel packages today?