Rabbitmq Sql Bundle Laravel Package

Technical Evaluation

Architecture fit — low. The package is a Symfony bundle (florianajir/rabbitmq-sql-bundle), not a Laravel package. There is no bundle registration mechanism in Laravel; the package's DI Extension, Configuration tree, and compiler passes will not auto-wire into a Laravel service container. The core value proposition — "SQL persistence with relationship support" — is implemented against Doctrine ORM metadata and entity mappings, which have no direct Eloquent equivalent. Porting the relationship logic is the expensive part, and it is precisely the part that does not survive the framework boundary. What is portable is the generic piece: a php-amqplib consumer loop that deserializes a message and writes a normalized graph into SQL tables.

Integration feasibility — low to moderate, with a fork. Composer constraints date from May 2016 (PHP 5.6/7.0-era, Symfony 2.7/3.0-era, contemporary Doctrine). Installing into a Laravel 10/11 app on PHP 8.2 will almost certainly fail dependency resolution; --ignore-platform-reqs is a trap, not a workaround. A viable integration requires forking and re-declaring constraints against PHP 8.x, modern php-amqplib, and the target DB driver — at which point the question becomes "why adopt the package at all" rather than "how do we install it."

Technical risk — high.

• Unmaintained: no release in ~9 years, no CI, no security policy, no visible issue triage.
• Negligible validation: 2 stars, 0 dependents. No production signal to borrow from.
• Bus factor 1, with no upstream to escalate to.
• Transitive dependency CVE exposure is unknown and unpatchable without a fork.
• 2016 PHP idioms (pre-typed-properties, likely deprecated php-amqplib APIs) raise subtle runtime risk on PHP 8, particularly around null handling and exception signatures.

Key questions to resolve before any commitment

1. What problem is actually being solved — durable event/audit persistence, or inter-service data sync? The answer changes build-vs-adopt.
2. Do we genuinely need relationship-aware persistence, or is an append-only table plus a projection job sufficient?
3. What is the message contract (schema versioning, IDs, ordering guarantees) and who owns the producer?
4. What throughput and latency envelope? 10 msg/s and 5k msg/s imply different architectures.
5. Which SQL engine, and are we allowed to own a fork with a named maintainer?

Recommendation: treat this repository as a reference implementation, not a dependency. Score 0.01 is consistent with abandonment; adopting it transfers an unbounded maintenance liability for a few hundred lines of consumer orchestration.

Integration Approach

Stack fit. In a Laravel context, the equivalent capability is composed, not installed:

• Consumer/transport: a maintained RabbitMQ bridge (e.g. vladimir-yuldashev/laravel-queue-rabbitmq) or direct php-amqplib inside a long-running artisan command.
• Persistence: Eloquent models with explicit belongsTo/hasMany relations, wrapped in DB::transaction.
• Reliability: ShouldQueue + failed_jobs, or an explicit dead-letter exchange if bypassing the Laravel queue abstraction.

Migration path. Three options, in ascending cost:

1. Reimplement (recommended). Lift the design — message envelope, table layout, consumer lifecycle — and rebuild on Laravel primitives. Estimate 1–2 engineer-weeks for a scoped first consumer, more if the relationship graph is deep.
2. Fork and de-Symfony-fy. Strip the bundle scaffolding, keep the persistence writer, re-map Doctrine metadata to Eloquent. Cheaper only if the relationship logic is genuinely intricate, and it leaves you owning abandoned code.
3. Adopt as-is. Not viable on a modern Laravel stack without dependency surgery.

Compatibility gaps to verify explicitly: PHP 8.2+, Laravel 10/11, MySQL 8 / Postgres 15/16, RabbitMQ 3.13 (quorum queues, publisher confirms). The 2016 client generation predates several of these; assume incompatibility until proven otherwise.

Sequencing.

1. Product/architecture spike: one message type, end-to-end, in a throwaway branch — timebox one week.
2. Define the message contract, schema, and idempotency key (unique constraint on message ID or business key).
3. Build the persistence/mapping layer with transaction boundaries per message.
4. Load test at target throughput with realistic relationship depth.
5. Shadow-run alongside the incumbent consumer; reconcile row counts.
6. Cut over, then retire the legacy path.

Operational Impact

Maintenance. A fork means permanent internal ownership: dependency patching, PHP major upgrades, and annual security review. Budget a recurring small-but-nonzero allocation (~5–10% of one engineer, plus a forced migration each time PHP or the DB driver majors). Upstream will not help.

Support. No vendor, no community, no documentation beyond a 2016 README. Any incident routes to an internal SME. That is single-point-of-failure knowledge — require a written runbook and a second trained engineer as a condition of go-live, or accept key-person risk.

Scaling. Throughput is bounded by three things the package does not manage for you: worker concurrency and prefetch (unbounded prefetch plus large messages causes memory blowup), relationship insert ordering under FK constraints, and SQL write contention as workers scale horizontally. Expect per-message transactions to be the throughput ceiling; batch inserts help but complicate failure semantics. Plan capacity testing at 2–3x forecast.

Failure modes to design against.

• Poison messages requeued indefinitely — need max-retry plus DLX.
• Partial writes if relationship inserts aren't transactional — orphaned parents or missing children.
• Duplicate inserts on redelivery — mandates an idempotency constraint, not application-level checks.
• Auto-ack misconfiguration — silent message loss under worker crash.
• DB connection exhaustion as worker count grows; connection-per-worker is not free.
• Stale AMQP connections without heartbeat/reconnect handling — worker appears healthy but consumes nothing. Requires a liveness check, not just a process check.

Ramp-up. Low discoverability, Symfony idioms in a Laravel shop, and no tests to read as documentation. Assume 2–3 days for a competent PHP engineer to understand the original design, and 1–2 weeks before they can safely modify the consumer. Factor this into the build estimate; it is the hidden cost that makes "just fork it" look cheaper than it is.