Weave Code
Bitter Bundle Laravel Package
rezzza/bitter-bundle
Symfony bundle that integrates the Bitter error-handling library, letting you map exceptions and errors to consistent HTTP responses through configurable handlers. Centralizes error management, keeps responses predictable, and makes failures easier to debug across your Symfony applications.
Implements a powerful analytics Symfony Bundle based on Bitter library using Redis bitmaps
Frequently asked questions about Bitter Bundle
- Can I use rezzza/bitter-bundle in a Laravel application?
- No. rezzza/bitter-bundle is a Symfony Bundle, so it registers services through Symfony's kernel and exposes a Symfony config tree that Laravel does not consume. The underlying rezzza/bitter library is framework-agnostic, and that is what you should depend on in Laravel. Treat the bundle as Symfony-only documentation for how to wire the client.
- What does rezzza/bitter-bundle actually add over rezzza/bitter?
- Its main contribution is dependency-injection wiring: it registers Bitter\Client in Symfony's container and provides YAML or PHP configuration for the key prefix and Redis client. Laravel has no equivalent bundle registration, so none of that wiring applies. You can reproduce the useful part with a singleton binding and a config file in roughly twenty lines.
- How do I install and configure rezzza/bitter directly in Laravel?
- Require rezzza/bitter with Composer, then bind a singleton in AppServiceProvider that constructs the client with your Redis connection's underlying client. Add config/analytics.php for the connection name, key prefix, TTL, and an enabled flag, and expose it through a facade or application-owned repository. Keep controllers and jobs behind that interface so Bitter\Client is never called directly.
- Does rezzza/bitter work with Laravel 10 and 11?
- The Bitter library is framework-agnostic, so Laravel version support depends mainly on your PHP version and the Redis client it accepts, not on Laravel's release number. The bundle itself has no Laravel integration and will not register in a Laravel app. Spike the exact PHP and Redis client combination before committing, because the package predates current Laravel releases.
- How should I design Redis bitmap keys and TTLs for Bitter in Laravel?
- Use a predictable layout such as bitter:{action}:{date} with an application-level prefix for tenant and environment isolation. Decide TTLs explicitly, because expiry determines memory growth and whether historical counts remain available. Centralize key construction in one class so prefix changes, date formatting, and retention rules cannot drift across call sites.
- Is Bitter's Redis bitmap counting exact, and what breaks accuracy?
- Bitmap counting with BITCOUNT is exact, not approximate like HyperLogLog, provided each user maps to a stable bit offset. Accuracy breaks if user IDs are recycled, renumbered, or mapped inconsistently, because old bits silently refer to different people. Very large or sparse IDs can also cause large bitmap allocations, so document and test your offset strategy.
- Can Bitter answer uniques by plan, country, and channel in Laravel?
- No, not directly. Bitmaps answer questions like how many distinct users did X on day D and support intersections of those sets, but they store membership rather than events. Arbitrary filters, funnels with step ordering, per-user timelines, and forensic drill-down require an event store or a different analytics system.
- Does Bitter support Redis Cluster, Sentinel, or multiple Laravel connections?
- The library operates on a Redis client you provide, so support depends on that client and your deployment. With Redis Cluster, BITOP across keys in different slots is a real concern, so keep related bitmap keys in the same hash slot. Verify Sentinel failover and connection handling in a spike rather than assuming bundle-era behavior.
- How do I test a Laravel integration with Bitter and Redis bitmaps?
- Use a real Redis instance in tests, such as a disposable container, because bitmap behavior is the thing you need to verify. Test key naming, TTL, offset derivation, BITCOUNT results, and intersection logic, and include a case with recycled or out-of-range IDs. Wrap Bitter behind an application interface so you can fake the repository in feature tests that do not need Redis.
- Is rezzza/bitter-bundle maintained, and what are the alternatives?
- The adoption signal is weak, with very few stars and no dependents, so assume it is unmaintained and validate correctness yourself. Alternatives include using rezzza/bitter directly behind your own interface, implementing the small BITCOUNT and BITOP calls yourself, using HyperLogLog when approximate uniques are acceptable, or adopting an event-based analytics store for richer questions. For Laravel, the direct-library or custom-repository path is usually the lowest-risk option.
Weaver
How can I help you explore Laravel packages today?