- Is experteam/api-redis-bundle a Laravel package?
- No. It is a Symfony bundle with a Bundle class, DependencyInjection extension, and YAML configuration under config/packages. Laravel has no bundle or extension lifecycle, so this is not a drop-in Laravel dependency. Treat it as a design reference only if you are working in Laravel.
- Can I install experteam/api-redis-bundle in a Laravel app?
- You can run composer require, but adopting the bundle in Laravel is not drop-in. You would need to port the container wiring into a ServiceProvider and config/api_redis.php, or use only its underlying classes through Composer autoload. The YAML config and vendor_copy.php post-install script do not fit Laravel conventions. For Laravel, use Illuminate\Support\Facades\Redis and Illuminate\Queue\RedisQueue instead.
- What does experteam/api-redis-bundle actually provide?
- It provides a Predis client wrapper for reading and writing Redis, plus a Redis Transport for saving entities and dispatching message queues. Configuration is YAML-based with per-entity prefix, save, message, and message_class settings, plus serialize_groups and an elk_logger toggle. Both capabilities are commodity concerns already covered by Symfony Cache and Messenger or Laravel Redis and Queue.
- Which Symfony versions does experteam/api-redis-bundle support?
- The README states Symfony 5.1+, but Symfony 5.1 is EOL and even 5.4 LTS is out of security support. There is no evidence it has been validated on Symfony 6 or 7. Pin exactly if experimenting on Symfony and add contract tests around the client and transport.
- Does experteam/api-redis-bundle have tests or CI?
- No. The README-only maturity implies no test suite, no CI badge, no changelog, and no tagged release cadence. With 0 stars, 0 dependents, and no known consumers, there is no issue history to mine for failure modes. Treat it as unmaintained third-party code.
- How does the Redis Transport handle message queues, retries, acks, and dead letters?
- The README does not describe dispatch semantics such as Redis lists versus streams versus pub/sub, at-most-once versus at-least-once delivery, retry and backoff behavior, dead-letter queues, or idempotency. For a queue transport, that is the entire risk profile. Do not rely on it for production queues without reading the source and writing contract tests.
- What is serialize_groups in experteam/api-redis-bundle?
- It configures serialization groups for save and message operations, likely reusing Symfony Serializer groups. The risk is over-exposure of entity fields into Redis payloads if groups are too broad. Audit the groups carefully and keep payloads minimal.
- Is the vendor_copy.php post-install script safe?
- No, it is risky. It copies the example YAML into config/packages on every composer install or update and mutates the host project's filesystem, causing CI drift and merge conflicts. If you must use the bundle on Symfony, vendor the config manually and skip the script. Better to avoid the pattern entirely.
- What should Laravel teams use instead of experteam/api-redis-bundle?
- Use Illuminate\Support\Facades\Redis for read and write operations, and Illuminate\Queue\RedisQueue, optionally Laravel Horizon, for dispatch. If you want an entity-prefix convention, implement it in a small ServiceProvider and config/api_redis.php under team ownership. Net new code is small and fully maintainable.
- What is the license and can I fork experteam/api-redis-bundle?
- It is MIT licensed, so forking is viable. However, there is no compelling reason to adopt it over first-party primitives; forking means owning maintenance, tests, and queue semantics. Consider it a 1 to 3 dev-day reference implementation if you want the entity-prefix and serialize-group convention internally.