- How do I install and configure realtime-job-batching for Laravel?
- Install it with Composer using composer require yogameleniawan/realtime-job-batching, then publish its config and add your Pusher credentials. You also need private-channel authorization in routes/channels.php and a frontend Laravel Echo subscriber. The package adds no new persistence or runtime; it wires Laravel batch lifecycle events to broadcast events.
- Which Laravel and PHP versions are supported by this package?
- The provided evaluation flags Laravel major compatibility as a real risk and says you must confirm the supported Laravel and PHP versions against the major you run. Native job batching exists from Laravel 8 onward, but this package's CI matrix and declared constraints are not established in the context. Check composer.json and run a one-day spike before committing.
- Does this package use Laravel's native Bus::batch() or implement its own batching?
- It is described as a thin convenience layer over Laravel's native Bus::batch() and the Batchable trait's progress() accessor. Its value is broadcasting batch lifecycle transitions, not reimplementing batch state or storage. Confirm in source that it calls Bus::batch() rather than maintaining its own batch tables.
- Is the package locked to Pusher, or can I use Reverb, Soketi, or Ably?
- The README positions it around Pusher, but the evaluation says you must verify whether it broadcasts through Laravel's BroadcastManager or binds the Pusher SDK directly. BroadcastManager would make Reverb, Soketi, or Ably more feasible; a direct Pusher binding raises exit cost. Inspect the event broadcasting implementation before choosing a driver.
- How do I secure private channels for realtime batch progress?
- Define authorization for the private or presence channels in routes/channels.php so only intended users can subscribe. Confirm the event payload does not leak job class names, counts, or other sensitive batch details to unauthorized subscribers. The evaluation lists channel authorization as a low but real security surface to verify.
- What queue driver and broadcasting setup does it require?
- You need broadcasting configured and a queue driver that supports Laravel job batching with a database-backed batch store, such as Redis or database queues. Sync and beanstalkd are not viable for batching, and apps without Echo/Pusher broadcasting get no benefit. The package sits between queue workers and the presentation layer without adding storage or protocol.
- How chatty is it for a 10,000-job batch?
- The evaluation warns that one broadcast per job completion is chatty, so a 10,000-job batch could hit Pusher message quotas or connection limits. Verify whether the package fires per job, per percentage tick, or with debouncing, and throttle or aggregate server-side if needed. Pusher quotas become the scaling ceiling for large batches.
- How does it report retries, allowFailures, and partial failures?
- Retries and allowFailures can produce double-counted or non-monotonic progress, and out-of-order delivery across workers can make a progress bar jump backwards. The evaluation says the package's exact semantics must be verified, especially for partial failures. Test a batch with retries and allowed failures before relying on the percentage in production.
- What happens if the final batch event is dropped or a worker dies?
- If the finally broadcast fails or a worker is killed, the UI can hang near completion with no recovery path. The evaluation recommends confirming whether a polling fallback or state reconciliation exists after a dropped connection. If not, add a status endpoint or reconnect handler that re-reads batch progress.
- Is it production-ready and maintained, and what alternatives should I consider?
- The evaluation rates bus factor and abandonment as high risk: 24 stars, zero dependents, a single maintainer, and a low composite score. It is not a differentiated infrastructure package; realtime batch progress is roughly 100 to 200 lines of glue over native batching and broadcasting. Alternatives include building that small broadcast layer yourself, using Horizon for operational telemetry, or polling the batch progress() accessor.