Messenger Laravel Package

Product Decisions This Supports

• Async workload strategy inside Ibexa DXP: this package is the vendor's Symfony Messenger wiring for Ibexa (bus, transports, handlers). It supports the decision of which workflows move off the request cycle — search index propagation, bulk content/asset imports, notification and email bursts, ERP/PIM sync, webhook fan-out, scheduled report generation.
• Build vs. buy: it is a "buy" artifact, not a build candidate. The capability ships with an Ibexa DXP subscription, so the real decision is "continue/extend Ibexa" versus "build our own queue and handler layer." Do not scope it as a standalone library dependency.
• Roadmap sequencing: if we are on Ibexa, async messaging is platform infrastructure on the critical path — it gates later features (large catalog operations, personalization pipelines, third-party integrations) rather than being a shippable feature itself.
• Diligence decision it does not support: anything in a Laravel roadmap. Despite the "Laravel/PHP" framing, this is Ibexa/Symfony-native. It does not slot into a Laravel queue/Horizon stack, and adopting Ibexa to obtain it is a platform commitment, not a library choice.
• Effort sizing input: because the README is an unfilled template (<!-- This package contains the ... functionality -->), discovery cost for our engineers is non-trivial — budgets should assume learning from Ibexa docs and source, not from this repo.

When to Consider This Package

• Only when the org already holds, or is actively evaluating, an Ibexa DXP subscription. The README states plainly: install Ibexa DXP to use this package. It is a split-out internal subpackage, not general-purpose software.
• When vendor-managed upgrade paths matter more than flexibility. The genuine value is that transport config and handler contracts survive Ibexa version bumps without us owning that maintenance.
• When licensing posture is already settled. Dual-licensed: Ibexa Business Use License (requires a valid subscription) and GPL-2.0 as an alternative. The registry reports NOASSERTION, so terms must be confirmed with the vendor — and the GPL branch is copyleft, which is a legal review item if we are not a BUL subscriber.
• Look elsewhere if:
  • We are a Laravel shop — use Laravel queues/Horizon, or Symfony Messenger directly.
  • We need docs, examples, or community support — 0 stars, 0 dependents, and a placeholder README mean zero independent adoption signal and effectively no external documentation.
  • We need a framework-agnostic message-bus abstraction across services.
  • We cannot accept a dependency whose release cadence and support are wholly coupled to a commercial product.
• Lock-in to price in: this package's health is entirely derivative of Ibexa's. If we churn off the platform, the dependency churns with it. That is acceptable only if platform lock-in is already a settled decision.

How to Pitch It (Stakeholders)

Executives: "This is a component of the Ibexa DXP product we license — not a community open-source library. Zero stars and zero external dependents confirm it is vendor-internal plumbing, not a market-validated tool. The only funding question worth asking is our Ibexa platform decision; async messaging comes bundled with it. If we are not on Ibexa, it is not a candidate and should not consume diligence cycles."

Engineering: "It is Ibexa's Symfony Messenger integration — genuinely useful inside Ibexa for offloading indexing, imports, notifications, and integrations to async workers, with the upgrade path owned by the vendor. Three caveats: the README is an unfilled template, so expect to learn the API from Ibexa docs and source; it is dual-licensed (BUL / GPL-2.0), so confirm which branch we consume before any code lands; and it is not applicable to our Laravel services. Recommendation: track it as an Ibexa-platform dependency, not an independent adoption. If we need async messaging outside Ibexa, standardize on the framework's native queue instead."