Radish Bundle Laravel Package

Technical Evaluation

jadu/radish-bundle is a Symfony bundle, not a Laravel package. That single fact drives the entire assessment: the artifact ships a Symfony Bundle subclass plus service/DI configuration that assumes a Symfony kernel, Symfony DependencyInjection, and Symfony Console. Radish itself (Jadu's Redis-backed job queue) is the substantive library; the bundle is a thin framework-wiring layer around it. The headline verdict is that the bundle has no direct path into a Laravel application, while the underlying queue concept does — and Laravel already ships a first-class equivalent.

Architecture fit. The bundle's job is to register queue/producer/consumer services into a Symfony container and expose console commands for workers. Laravel's container (Illuminate\Container) is not Symfony DI, and Laravel has no bundle registration mechanism. To use the bundle unchanged you would need a Symfony runtime somewhere in the estate. In a Laravel-first codebase, every path forward is really a decision about the Radish library, not the bundle. Meanwhile Laravel's native queue abstraction with the Redis driver (optionally Horizon) already covers producers, workers, retries, backoff, failed-job storage, and supervision — which is the majority of Radish's surface area. Architecture fit is therefore poor as a drop-in, neutral as a reference implementation.

Integration feasibility. Three realistic options, in descending order of effort:

• Symfony sidecar: stand up a small Symfony service running the bundle, sharing Redis with Laravel. Feasible, but introduces a second framework, a second deploy pipeline, and a second set of runtime conventions for one queue. Roughly 3–5 engineer-days for a skeleton plus ongoing dual-stack cost.
• Library-only port: depend on the Radish core library and hand-write an Illuminate\Support\ServiceProvider wrapper (container bindings, config publishing, worker command wrapping radish:worker semantics). The bundle's value-add is small enough that this is the sane path — but it is now your code, and you inherit the queue's semantics wholesale.
• Don't integrate: reimplement on Laravel's native Redis queue, or adopt the bundle only as a design reference for status tracking. Lowest risk.

Technical risk. Zero stars, zero dependents, and a zero aggregate score with a 29.29 opportunity signal means essentially no community vetting: no third-party security review, no CVE history, no Stack Overflow corpus, no battle-tested edge cases surfaced by other users. The bus factor is one team at one vendor. A 2024-12-06 tag shows the repo isn't archived, but a release with no dependents is not evidence of health — validate whether it was a dependency bump or a substantive change. Additional risks: Redis key/schema ownership is undocumented, so any future migration off Radish requires reverse-engineering your own production data; job payload serialization is opaque to Laravel's tooling (no Horizon introspection, no queue:failed visibility); version constraints against current Symfony/PHP must be checked before the sidecar option is realistic. MIT licensing is clean — no legal obstacle.

Key questions.

1. Is the 2024-12-06 release a functional change or an automated dependency bump?
2. What Redis keys/structures does Radish write, and what is the documented retention story?
3. What delivery guarantees does the queue offer — at-least-once, at-most-once, visibility timeouts, dead-lettering?
4. Does the core library carry a hard Symfony dependency, or can it be container-agnostic under a Laravel service provider?
5. What specific capability does Radish provide that Laravel's Redis queue plus Horizon does not?
6. Are there production references from Jadu's own platform we can speak to?
7. What is the current maintenance commitment from Jadu — is this a supported product or an internal extraction?

Integration Approach

Stack fit. Weak. A Laravel application would be integrating a foreign framework's configuration dialect. The clean seam is Redis, not PHP: Laravel and a Symfony sidecar can share a Redis instance, but they cannot share a container, an event dispatcher, or a console application. Any "integration" is really an inter-process contract over Redis keys — which must be specified and versioned by us, not by the vendor.

Migration path. Recommended sequence: (1) freeze scope to a single low-risk queue, (2) build the library-only wrapper in a branch behind a feature flag, (3) run it in parallel with a native Laravel queue job for the same workload and diff outcomes, (4) only then route production traffic. If the goal is long-term maintainability, plan the exit at the same time as the entry — write the queue abstraction against a Laravel contract so Radish is swappable. If the team cannot commit to owning a fork or a wrapper, the honest recommendation is to skip Radish and use the native queue, documenting Radish's status-tracking model as inspiration.

Compatibility. Verify PHP version support against your runtime, Symfony component versions required by the bundle, and the Redis client (Predis vs phpredis) — Laravel's Redis integration leans on phpredis/Predis too, and mismatched clients across two runtimes in one Redis instance is a subtle source of connection-pool and serialization bugs. Confirm the bundle does not assume Symfony's kernel.environment or cache warmup semantics that have no Laravel analogue.

Sequencing. Do not begin with code. Week 1: answer the key questions above and get a written position from Jadu on support. Week 2: capability gap analysis against Laravel's queue plus Horizon — if the gap is "status visibility," that is a small custom table, not a new queue. Week 3–4: only if a genuine gap survives, prototype the library-only wrapper. Treat the sidecar option as a fallback requiring a second-stack owner, not a default.

Operational Impact

Maintenance. The effective maintainer is us. With zero dependents, there is no upstream community to catch regressions, and no expectation that a CVE in a transitive dependency is patched promptly. Budget for a named owner, a pinned-version policy, and a documented fork procedure; without that owner, the integration decays silently.

Support. No vendor SLA, no commercial backing evidenced by the package metadata. On-call runbooks must be authored internally: how to inspect queue depth, how to requeue, how to drain. Compare against Horizon, where the operational tooling is free and widely understood by hiring candidates.

Scaling. Scaling is worker-count against Redis throughput — the same model as Laravel's queue, so no structural advantage. Watch Redis memory: Radish-style status tracking can accumulate keys per job, and without a documented TTL policy, memory growth becomes an incident class of its own. Cross-runtime sharing of one Redis instance also means one noisy neighbour can affect both stacks.

Failure modes. Anticipated risks to design against: Redis connection loss with unclear in-flight job recovery; poison messages with no dead-letter path visible to Laravel operators; duplicate execution under at-least-once semantics absent idempotency keys; silent worker death in the sidecar with no supervisor familiar to the Laravel on-call; and schema drift if the vendor changes key layout in a patch release. Each needs a written mitigation before production.

Ramp-up. Steep and asymmetric. An engineer must learn Radish's model and a second framework's runtime conventions to debug a single queue. The knowledge is non-transferable — it does not appear in Laravel job postings and will not be reinforced by the wider team. Weigh that against a native implementation where ramp-up is near zero and the debugging surface is one stack.

Recommendation. Do not adopt the bundle as-is. Pursue only the library-only wrapper if a validated capability gap exists and a named owner accepts the fork burden; otherwise implement on Laravel's native Redis queue and use Radish as a reference for status tracking.