Product Decisions This Supports
- Build vs. buy vs. borrow for messaging infrastructure. This package is a candidate "borrow" for a Symfony message bus (command/query/event dispatch with handler resolution). Evaluating it forces the real decision: adopt a third-party bus, standardize on Symfony Messenger, or maintain a thin in-house abstraction.
- Roadmap sequencing for service-to-service communication. If your architecture splits along microservice boundaries, the bus contract is a foundational dependency. Deciding it early prevents a costly retrofit once handlers and message shapes proliferate.
- Framework and upgrade planning. The package targets Symfony 4 and its last release was April 2019. Any decision to depend on it directly constrains your Symfony upgrade path, since Symfony 4 is end-of-life and PHP 8+ compatibility is unverified.
- Feature scoping for an internal bus. Even if you don't adopt it, its surface (message dispatch, handler registration, middleware) is a useful checklist for what your own abstraction must cover, so scope is defined by evidence rather than guesswork.
- Interoperability with existing Garlic-based services. If any owned service already uses this bundle, the assessment determines whether that service is a migration candidate or a bounded legacy island.
- Vendor and supply-chain risk posture. MIT licensing and Composer distribution mean legal exposure is nil and forking is permitted — the risk is maintenance, not licensing. That distinction should shape the risk register entry.
When to Consider This Package
Consider it only if:
- You own a legacy service already built on Symfony 4 and this bundle, the service is stable and slated for replacement rather than growth, and changing the bus now carries more risk than leaving it.
- You need a reference implementation to read before writing your own — the code is small, MIT-licensed, and demonstrates the pattern.
- You are prepared to fork and take full ownership: patching for supported Symfony/PHP versions, adding tests, and publishing internally.
- The team is already fluent in Garlic conventions and the cost of divergence outweighs the cost of maintenance.
Look elsewhere if:
- You are starting anything new. Six stars, zero dependents, and no release since 2019 indicate effectively no community, no security response, and no bug-fix path — you would be the only maintainer in practice.
- You need a supported Symfony version (5.4, 6.x, 7.x) or PHP 8.1+. Compatibility is unproven and likely broken; validating it is unbudgeted work.
- You need SLAs, security patching, documented upgrade guides, or an on-call escalation path. None exist here.
- Your bus needs are conventional. Symfony Messenger is first-party, maintained, and covers transport, retries, middleware, and failure handling. Building your own is defensible only for a genuinely unusual dispatch model.
- You require async transport, observability, or dead-letter handling out of the box — you would be building those on top of an unmaintained base.
- Procurement or security review requires a maintained dependency with a release cadence. This will not pass.
How to Pitch It (Stakeholders)
Recommendation: do not adopt for new or growing services. Use Symfony Messenger, or fund a small in-house bus if dispatch semantics genuinely differ.
This is a Symfony 4 message bus bundle for Garlic microservices, MIT-licensed, last released in April 2019, with six GitHub stars and no known dependents. It is not a maintained product; it is an unmaintained artifact with an expired framework target.
The licensing is clean and the code is forkable, so there is no legal or lock-in obstacle — but there is also no maintainer, no security response, and no upgrade path. Adopting it means our team silently becomes its sole maintainer, and the first Symfony or PHP upgrade converts that hidden cost into a scheduled project.
The pragmatic position: treat it as a bounded legacy concern, not a platform choice. Where it already exists, contain it and plan migration. Where it does not, standardize on Symfony Messenger — first-party, actively maintained, and covering the transport, retry, and failure-handling work we would otherwise rebuild. If our dispatch model is genuinely non-standard, scope a thin internal abstraction instead; that is a small, owned, and testable commitment rather than an indefinite dependency on an abandoned package.