Product Decisions This Supports
- Scaling decision for notification-heavy features: The 1.0.11 release moves Android push delivery to a chunked send model with a fixed batch size of 750, defined as a class constant on
AndroidPush. This is the difference between "we can notify 10k users in one job" and "we silently time out or hit provider payload limits." It directly de-risks any roadmap item that assumes broadcast or segmented push (promotions, digests, re-engagement campaigns, transactional fan-out to large cohorts).
- Build vs. buy for the delivery layer: The package appears to own the FCM/Android transport concerns — token batching, request construction, response handling — that you would otherwise hand-roll in a queued job. If your team's remaining work is only the "who and when" logic (segmentation, scheduling, templates, opt-out), that's a strong argument for buying/using rather than building.
- Capacity and cost planning: Chunked sending changes the shape of your queue and worker load. 10,000 recipients now means ~14 sequential provider calls instead of one unbounded call. That affects job duration, retry windows, timeout settings, and worker concurrency targets — inputs to your infrastructure budget conversation, not just an engineering detail.
- Sizing and SLA commitments: The fixed 750 constant gives you a predictable throughput unit. You can model "time to notify the full audience" for launch-day campaigns and commit to an internal SLA (e.g., "all users notified within 10 minutes") rather than guessing.
- Prioritization of follow-on work: Because the chunk size is a hardcoded constant rather than a config value, any product requirement that asks for tunable throughput (per-tenant limits, large-account tiering, throttling for cost control) becomes a distinct backlog item requiring a code change or upstream contribution. That's a scoping decision you now know to make early.
When to Consider This Package
Adopt it when:
- Android push is a real product surface, not a checkbox — you have campaigns, alerts, or transactional notifications going to audiences measured in thousands.
- You want push delivery to live inside the Laravel queue/worker model you already operate, rather than adding a separate notification service or vendor SDK integration.
- Your audience sizes have outgrown single-request sends and you need batching out of the box instead of writing chunking logic yourself.
- You are comfortable with the trade-off that delivery behavior is controlled by code constants — meaning changing batch size, retry semantics, or provider endpoints requires a release, not a config edit.
Look elsewhere or pause when:
- You need multi-platform parity (APNs/iOS, web push) with one consistent delivery abstraction — this release addresses Android only, and it is unclear whether iOS gets equivalent chunking.
- You require runtime configurability or per-tenant tuning of batch size, rate limits, or credentials without deploying.
- You need first-class delivery observability — per-chunk success/failure metrics, partial-failure reporting, dead-token suppression — as a product requirement; constants-based chunking alone does not evidence that.
- You're operating at a scale where you'd rather delegate delivery to a managed service (FCM admin SDK wrappers, OneSignal, Pusher Beams) and treat push as infrastructure you don't own.
Also treat the 1.0.x version line as a signal: pre-2.0 packages can and do change delivery behavior in patch releases, as 1.0.11 demonstrates. Budget for regression testing on every bump.
How to Pitch It (Stakeholders)
For executives: This package is the Android push delivery layer for our Laravel application. The new release fixes a scaling ceiling we would have hit the moment we tried to notify a large audience at once — sends are now broken into batches of 750 instead of being fired in one oversized request. The practical effect is that large campaigns become reliably deliverable rather than a timeout-and-retry gamble. It's a small change with an outsized impact on anything on the roadmap involving broad notification.
For engineering: Version 1.0.11 chunks Android pushes at 750 recipients per request, with the batch size hardcoded as a constant on AndroidPush. Two things to verify: (1) queue job timeouts and worker concurrency still fit the new multi-request execution shape, and (2) partial-failure handling — if chunk 7 of 14 fails, do we retry the whole job and double-send to the first six chunks? Also flag that iOS chunking parity is unconfirmed. We should pin the version and add a delivery test at >750 recipients to our suite before relying on it.
Recommendation: Proceed with adoption, pin to 1.0.11, and open a follow-up to either upstream a configuration-driven batch size or vendor the constant — because per-tenant throttling and cost control are questions we will be asked, and right now the answer requires a deploy.