Amqp Rpc Transporter Bundle Laravel Package

Product Decisions This Supports

• Transport pattern selection: Informs whether to introduce request/response (RPC) semantics over your existing AMQP broker versus keeping messaging strictly fire-and-forget and doing synchronous work over HTTP/gRPC. This is an architecture decision with downstream consequences for latency budgets, retry/timeout design, and observability.
• Build vs. buy for infrastructure glue: The package's scope is narrow — it wires AMQP reply-queue and correlation-ID handling into Symfony Messenger's transport abstraction. That's a decision input for whether you vendor a small dependency or write and own ~200–400 lines of internal code.
• Stack-fit triage: Despite being surfaced as a Laravel/PHP package, this is a Symfony bundle that integrates with symfony/messenger. For a Laravel codebase it is not adoptable without meaningful porting work — that alone may close the evaluation.
• Feature feasibility for async workflows: Useful for scoping features that need a caller to block on a worker result (e.g., report generation, document conversion, third-party calls that must return to a web request) without standing up a separate RPC framework.
• Roadmap risk input: With 2 stars, 0 dependents, and a 0.14 score, this is a signal for a "no external dependency" roadmap constraint rather than a capability unlock.

When to Consider This Package

Consider it only when all of the following hold:

• Your service is on Symfony with symfony/messenger already configured against RabbitMQ/AMQP — this is not a Laravel package.
• You have a genuine need for correlated request/response over the broker: worker results must return to the originating process, and a plain queue + database polling or an HTTP call is materially worse.
• Volume is modest and internal — back-office tooling, admin-triggered jobs, migration scripts, prototypes — where you can tolerate timeout edge cases and manual reply-queue cleanup.
• You're explicitly evaluating the pattern, using the package as a readable reference implementation to fork or reimplement in-house.

Look elsewhere when:

• Stack mismatch: Laravel, or any non-Symfony runtime. There is no maintained Laravel equivalent here.
• Production criticality: 2 stars and 0 dependents means no community bug-finding, no security response, no compatibility guarantees across Symfony Messenger majors (the transport API has changed more than once). Assume you own maintenance from day one.
• Throughput or latency SLOs: Broker-mediated RPC adds two hops plus queue depth variance; gRPC, or a plain HTTP service, is the better default.
• Contract rigor: You need schema-enforced request/response types, versioning, and per-method SLAs. This package provides transport plumbing, not a service contract layer.
• Ecosystem alternatives fit: gRPC (typed, fast, mature tooling), Temporal (durable workflows with real retry/timeout semantics), or Symfony Messenger's native fire-and-forget plus a result store — all beat a two-star bundle on operational confidence.

How to Pitch It (Stakeholders)

To executives: This is a small, single-maintainer Symfony bundle that adds request/response messaging on top of RabbitMQ. It is not a strategic dependency and it is not compatible with our Laravel services. Recommendation: treat it as a design reference, not an adoption. If we need this capability, we implement a thin internal version we control, or we standardize on gRPC — either path avoids taking on a dependency with zero production users.

To engineering: Valuable as a compact, readable example of correlation-ID and reply-to handling in Symfony Messenger — worth a 30-minute read before we write our own. Do not pull it into a service: no dependents means we absorb all upgrade and bug risk, particularly across Messenger major versions. If the RPC-over-AMQP pattern is genuinely required, scope it as a small internal transport with tests and on-call ownership, and compare against gRPC and a simple result-table approach before committing.