Broadcasting Laravel Package

Product Decisions This Supports

• Build vs. buy for real-time UI: This release moves the package from "broadcasts model changes" to "broadcasts table changes with a testable, typed contract." That is the difference between a prototype convenience and something you can put behind a customer-facing live view. The build alternative is 2–4 weeks of engineering for event plumbing, channel naming, queue handling, and test scaffolding — plus permanent maintenance.
• Feature roadmap — live data surfaces: Enables real-time tables/dashboards (ops monitoring, collaborative admin views, live status boards, activity feeds) without a separate CDC or websocket pipeline. If "live" is on the roadmap for multiple screens, adopting now amortizes the cost across each one.
• Quality investment, not just capability: TestQueueAdapter plus assertBroadcastQueued, assertBroadcastQueuedToChannel, and assertNoBroadcastsQueued let us assert broadcast behavior in the suite instead of manually faking the queue per test. This directly reduces regression risk on the highest-risk part of real-time features — "did the event actually go out, on the right channel, once?"
• Type safety as a maintenance lever: BroadcastingTraitInterface gives a static-analysis-friendly contract. That lowers the cost of onboarding engineers and of writing custom broadcast behavior later, and it makes future refactors of table classes safer.
• Separation of concerns → upgrade velocity: Moving logic out of BroadcastingBehavior into BroadcastingTrait is an internal quality signal. It means broadcasting can be composed onto classes beyond tables if the roadmap calls for it, and it reduces the chance that a behavior change forces a fork.
• Upgrade-cost decision (this release specifically): The breaking change shipped in a minor version (1.1.0). That is a semver signal worth flagging — we should budget a migration task and pin the version until it's done.

When to Consider This Package

Adopt when:

• We have (or are committing to) websocket broadcasting infrastructure — a configured broadcast driver and queue workers — and want table-row changes to reach clients without hand-rolled observers and events.
• More than one screen needs live updates. At one screen, a bespoke observer is cheaper; at three or more, this package wins.
• Broadcast correctness must be tested in CI. The new queue assertions and TestQueueAdapter are the strongest reason to take 1.1.0 specifically rather than staying on 1.0.x.
• The team is on a PHPUnit version compatible with 12.5 (PHP 8.3+) for the package's dev toolchain, and can absorb a one-time migration: every table class using BroadcastingBehavior must now also use BroadcastingTrait and implement BroadcastingTraitInterface.

Look elsewhere (or defer) when:

• No websocket/queue infrastructure exists and none is planned — the package becomes unused dependency weight.
• We cannot absorb a breaking change in a minor release. Pin to 1.0.x, confirm the 1.0 line still receives security/patch fixes, and revisit at 2.0.
• Volume and latency requirements are extreme (very high write throughput, strict sub-100ms fan-out). At that point evaluate database CDC (e.g., Debezium) or a dedicated event stream rather than model-layer broadcasting.
• We only need transport (Pusher/Ably) — those are complements, not substitutes; this package handles the application-layer contract, not delivery.
• The team already standardized on a different real-time convention (Livewire polling, Inertia + SSE). Mixing patterns has a real cognitive cost.

Open questions to resolve with the maintainer before committing: Is there a migration guide for the 1.1.0 breaking change? Is 1.0.x still supported? Are the new test helpers stable API or likely to churn?

How to Pitch It (Stakeholders)

To executives: This package is the cheapest credible path to live-updating screens. Version 1.1.0 adds the two things that make a dependency safe to bet on — automated tests for broadcast behavior and a typed contract for the code. The cost is a contained, one-time upgrade (add a trait and an interface to existing table classes) and no new infrastructure. The alternative is building and maintaining the same event plumbing ourselves. Recommendation: adopt for the live-dashboard workstream, pin the version, and schedule the migration as a discrete ticket rather than letting it surface mid-sprint.

To engineering: 1.1.0 is a breaking change in a minor release. Broadcasting logic moved out of BroadcastingBehavior into BroadcastingTrait; BroadcastingBehavior now requires both the trait and BroadcastingTraitInterface. Migration per table class is mechanical but must be exhaustive — miss one and it fails at runtime, not compile time. In exchange we get TestQueueAdapter and queue assertions, which let us cover "did we broadcast, to the right channel, exactly once" in CI instead of hoping. PHPUnit moved to 12.5, so verify our test toolchain and PHP 8.3+ baseline before upgrading. Suggested sequence: inventory BroadcastingBehavior usages → migrate on a branch → add broadcast assertions to existing table tests → ship.