Notification Pusher Laravel Package

Product Decisions This Supports

Feature scoping — push as a thin, owned channel vs. a product platform. NotificationPusher is a transport layer: you give it a payload and a list of device tokens, and it talks to APNs/GCM. That makes it a fit for the narrow, high-value slice of push — transactional, event-triggered, single-message notifications (order shipped, payment failed, appointment reminder, security alert). It does not support the product-platform slice (segmentation, journeys, A/B subject-line testing, frequency capping, in-app messaging, deliverability dashboards). Choosing this package is implicitly a decision to defer the platform slice, and that trade-off should be made explicitly, not by default.

Build vs. buy. This is the "build, but don't build the socket" option. It eliminates the per-message SaaS fee and vendor lock-in for a commodity channel, at the cost of owning operational concerns: token lifecycle, retry/backoff, queueing, credential rotation, and protocol currency. Useful framing: managed push vendors (OneSignal, Braze, Airship, AWS Pinpoint) are priced on marketing/engagement push; this library is adequate only for operational push. If our roadmap has engagement push in the next 12 months, adopting this buys us a migration, not a saving.

Roadmap sequencing and reversibility. Because the library is framework-agnostic and dependency-free relative to Laravel, wrapping it behind an internal PushGateway interface is cheap. That supports a decision to ship push in one sprint for an MVP or a single-tenant B2B integration, while preserving the option to swap the adapter for FCM v1 + APNs HTTP/2 or a SaaS later without touching domain code.

Dependency and risk decisions. 1,179 stars with 0 Packagist dependents is the signal that matters. Stars measure historical interest; dependents measure whether the ecosystem trusts it in production. That combination should route this to "adopt only with a fork-and-own plan," not "adopt and forget."

Concrete use cases to green-light: internal/ops device alerts; a single first-party iOS/Android app where we already store tokens; B2B deployments where per-message SaaS pricing is unacceptable; proof-of-concept work where the goal is validating the notification content and trigger logic, not the delivery infrastructure.

When to Consider This Package

Adopt when these are all true:

• Stack fit: PHP/Laravel backend, and you're willing to write the ~50-line service provider, config, and queued job yourself — there is no first-party Laravel package here.
• Scope: transactional/operational notifications only. Every message is triggered by a known domain event and targeted at a known user; you have no need to build audiences inside the push tool.
• You already own the hard parts: device token capture, deduplication, invalidation on uninstall, per-user preference/quiet-hours logic, and a queue (Laravel Horizon/Redis) with retry policy.
• Volume and SLOs are modest: thousands to low-hundreds-of-thousands per day, best-effort delivery, no contractual delivery SLA.
• Engineering accepts ownership: someone is named to fork it, pin the version, and patch transport changes.

Look elsewhere when any of these are true:

• Protocol currency is unverified. Apple retired the binary APNs protocol and GCM was shut down in favor of FCM v1. Before any commitment, a one-day spike must prove the adapters speak APNs HTTP/2 (preferably token-based .p8 auth) and FCM v1 (HTTP v1 + OAuth2 service account). If they only speak legacy APIs, this is a no regardless of stars.
• You need engagement features — segmentation, scheduling, journeys, analytics, A/B tests, localization management, frequency capping. Buy.
• Compliance or scale — regulated data, multi-tenant isolation, or sustained high throughput. Build on a maintained SDK (kreait/firebase-php, edamov/pushok) or buy.
• You want a supported, maintained dependency. With zero dependents and low recent activity, the maintenance risk is yours. Prefer laravel-notification-channels (fcm/apn channels) or kreait/firebase-php if you want something the ecosystem is actively exercising.

Recommendation: evaluate as a transport adapter inside an owned abstraction, gated on the protocol spike. Do not adopt it as the notification platform.

How to Pitch It (Stakeholders)

To executives (one paragraph): Push notifications are a commodity channel, but the vendors selling them price on engagement features we don't yet need. This library lets us ship transactional push — shipment updates, payment failures, security alerts — in days rather than weeks, with no per-message cost and no vendor contract. The trade-off is engineering ownership: roughly a few days of integration plus ongoing responsibility for credential rotation and keeping up with Apple/Google API changes. The package itself is mature in design but lightly maintained (1,179 stars, zero downstream packages depending on it), so we treat it as code we own — we fork it, pin it, and wrap it so we can replace it with a managed service or a maintained SDK later without rewriting product logic. Ask: approve a one-day technical spike to confirm it supports current Apple/Google APIs before we commit; if it doesn't, we fall back to a maintained SDK for the same effort.

To engineering (the honest version): It's a clean, framework-agnostic adapter pattern with a small API surface — easy to drop into a queued Laravel job and easy to mock in tests. It is also not a Laravel package, not actively maintained, and has effectively no downstream adoption. So: wrap it behind an interface, pin the version, own the fork, and verify current APNs/FCM protocol support before we build anything on top of it. If the spike fails, the interface means the swap costs us a day, not a sprint.

Decision requested: fund the protocol spike; approve "wrap-and-own" as the adoption stance; confirm we are deliberately deferring engagement/marketing push to a later buy decision.