Pushwoosh Laravel Package

Technical Evaluation

TPM recommendation (updated for v4.0.0): The recommendation is unchanged in substance — still a thin, tactical Laravel notification adapter for Pushwoosh, still gated by a spike and a fallback plan — but the maintenance signal has improved. v4.0.0 adds Laravel 13 support, which directly answers the "is it stale?" question that drove much of the prior risk. The trade-off is that the risk profile has shifted from abandonment to fresh-major-release: v4.0.0 is new, thinly documented, and has almost no field validation. Adopt only after pinning and verifying the actual Laravel/PHP support range in composer.json and CI.

• Architecture fit: Unchanged. Fits applications on Laravel Notifications with Pushwoosh as the push delivery provider, keeping channel selection inside via() rather than a bespoke HTTP client. The v4.0.0 bump means the package now fits teams standardizing on Laravel 13, which modestly widens the addressable stack. Still a poor fit for non-Laravel services, teams already standardized on another push provider, or products needing Pushwoosh capabilities beyond basic sends.
• Integration feasibility: Improved. Active support for the current Laravel major reduces the "will this install and run" risk and is a reasonable proxy for the maintainer still being engaged. Installation path is unchanged: Composer, Pushwoosh credentials, channel added to notification classes, delivery via existing queues. MIT license unchanged. The remaining feasibility work is verifying exactly which Laravel/PHP versions v4.0.0 supports and whether the major bump carries behavioral changes or only constraint changes.
• Technical risk: The dominant risk has moved. Staleness risk is lower; upgrade risk is higher. A 3.6.0 → 4.0.0 jump is a semver-major signal, and the release notes describe only "Laravel 13 support" via a single PR from a first-time contributor. That most likely means dropped support for older Laravel/PHP versions, but it could also include unlisted changes. Because the package still has 0 dependents and minimal community validation, there is very little external evidence that v4.0.0 works in production. Additional risks: undocumented breaking changes, a single-maintainer/single-PR release cadence, no changelog detail on migration, unclear CI matrix, and the unchanged constant risk that Pushwoosh SaaS — not the package — is the critical dependency.
• Key questions:
  • What exactly changed in v4.0.0 beyond the Laravel 13 constraint — any API, config, payload, or namespace changes?
  • Which Laravel and PHP versions does v4.0.0 support, drop, and test in CI?
  • Is there a documented upgrade path from 3.6.0, and is it a no-op for teams not on Laravel 13?
  • Does the release include functional or test changes, or is it a constraint-only bump?
  • Does it support the Pushwoosh features we need: targeted pushes, data payloads, badges, deep links, delivery receipts, multi-app configuration?
  • How are device tokens registered, refreshed, invalidated, and cleaned up?
  • Does it integrate cleanly with Laravel queues, retries, backoff, and failed-job handling?
  • What happens on Pushwoosh auth failure, rate limiting, timeout, or malformed payload?
  • Is there a responsive maintainer path and a release cadence we can plan around, or was this a one-off contribution?
  • What is the fallback if the package stalls again: fork, direct API client, or alternate provider?

Integration Approach

• Stack fit: Strong only where the stack is Laravel + Laravel Notifications + Pushwoosh. Keep the package behind an internal notification interface or service boundary so product code does not import the channel class directly. That boundary is what makes a v4 → v5 upgrade, a fork, or a provider swap a contained change rather than a refactor.
• Migration path: Two distinct paths now. Teams on Laravel 13 have no choice — v4.0.0 is the entry point, and they should spike it directly. Teams on older Laravel should stay pinned to 3.6.0 unless there is a specific reason to move, and treat the v4 upgrade as a separate, scheduled change rather than an incidental Composer update. If Pushwoosh is already the provider, introduce behind a feature flag on one low-risk notification type, then expand. Keep provider migration (FCM/APNs → Pushwoosh) separate from package adoption; device-token migration and re-consent are product risks, not package risks.
• Compatibility: Validate composer.json constraints, package auto-discovery, PHP version, queue driver behavior, and Pushwoosh API version before committing. Explicitly diff v3.6.0 against v4.0.0 to determine whether the major bump is constraint-only. Test against the application's actual Laravel/PHP matrix, not the package's claimed matrix. Confirm multi-tenant or multi-app Pushwoosh configuration support if relevant.
• Sequencing:
  1. Read the v4.0.0 diff and composer.json to establish supported Laravel/PHP range and whether behavior changed.
  2. Run a non-production spike on the target Laravel version with real Pushwoosh credentials and one notification type.
  3. Review package source, tests, release history, and open issues, including response times on the v4.0.0 PR.
  4. Wrap the channel in an internal adapter with config validation and structured logging.
  5. Add queueing, retry/backoff, rate-limit handling, and failure alerts.
  6. Pilot with internal users or a small cohort.
  7. Measure delivery success, latency, and support burden before expanding.
  8. Define the fallback path before making it critical-path infrastructure.

Operational Impact

• Maintenance: Low code volume, meaningful ownership burden — unchanged. The v4.0.0 release is a modest positive indicator that the package is not abandoned, but a single PR from a first-time contributor is not a durable maintenance commitment. Assign an internal owner, pin versions explicitly (3.6.0 or 4.0.0, never a floating range), watch upstream releases, and be ready to fork or replace. Document Pushwoosh API usage and configuration internally so package knowledge is not the only integration knowledge.
• Support: Still community/GitHub only, no SLA. Pushwoosh vendor support covers the SaaS platform, not Laravel integration defects. Establish an internal escalation path for credential rotation, provider outages, and notification failures. Note that v4.0.0 support questions will have a very small pool of people who have hit the same issues.
• Scaling: Unchanged. Delivery scale is a Pushwoosh plan and API-rate-limit concern; application scale is a Laravel queue-worker concern. Use queues, batch where appropriate, monitor throughput and 429s, and never send high-volume pushes synchronously in request paths.
• Failure modes: Expired or misconfigured credentials, Pushwoosh rate limits, network timeouts, invalid device tokens, duplicate sends after retries, missing delivery receipts, payload/schema mismatches, queue backlog, and silent failures where notifications are marked sent but never delivered. Add two v4-specific ones: an upgrade that silently drops support for the app's Laravel/PHP version, and a fresh-major regression with no community reports to surface it early. Add idempotency and observability around the channel regardless of version.
• Ramp-up: A Laravel developer can still integrate the happy path quickly. Production readiness requires Pushwoosh account setup, device testing, queue/retry behavior, failure-mode validation, and — new for this release — an explicit v4.0.0 upgrade test on the target Laravel version. Budget the short spike plus hardening time. Treat Laravel 13 support as evidence of life, not as evidence of production readiness.