Web Push Bundle Laravel Package

Technical Evaluation

Architecture fit — still weak, and the v7.0.0 release reinforces the finding rather than reversing it. The package remains a Symfony bundle: a DI extension, service definitions for the Minishlink\WebPush\WebPush client, configuration under config/packages/, and autowiring. None of that exists in a Laravel application, and pulling symfony/framework-bundle in to satisfy it remains a non-starter. The substance still lives in the framework-agnostic upstream library, minishlink/web-push, which we can wire in ~40 lines of a service provider. Treat the bundle as documented configuration shape, not a dependency.

What v7.0.0 actually tells us. The release notes are a pointer, not a changelog: the migration path is "go read web-push-php v11.0.0" plus a bundle doc page on customizing the HTTP client. Read that as two signals:

• The bundle is a follower, not a driver. Its own major version is defined entirely by an upstream major version. That is exactly the double-upgrade coupling predicted in the prior assessment, now observed: adopting the bundle means every web-push-php major forces a bundle major, plus eventual Symfony major churn, for zero Laravel benefit. This is now concrete evidence rather than a forecast.
• HTTP transport is now explicitly pluggable. A dedicated "customizing the HTTP client" doc page implies the underlying PSR-18 client can be injected. That is genuinely useful for us — it is the seam where we enforce concurrency caps, timeouts, per-host circuit breaking, and observability middleware, and where we can align with whatever HTTP client Laravel is already configured with. Positive signal, but it accrues to the library path, not the bundle path.

Integration feasibility — unchanged and high, via the library. The functional requirement (VAPID signing, aes128gcm payload encryption, POST to browser endpoints, 201/404/410 handling) is unchanged. The integration work remains small. The one change to sequencing is that any spike should now pin web-push-php v11 explicitly and be preceded by a read of its migration guide, because a major version bump on the crypto/transport layer is where silent breakage lives.

Technical risk. Moderate, with the composition shifting slightly:

• Adoption signal — marginally better, still poor. A maintained major release is better evidence of life than a quiet repo, and it materially softens the earlier "future-dated release / possible abandonment" concern. But dependents and stars have not changed in our data, bus factor is still one maintainer, and there is still no public production-use pool to draw on. Do not upgrade the adoption verdict on the strength of one release.
• Upstream major-version risk — now the top technical item. web-push-php v11 is a major bump. Before committing we must confirm: minimum PHP version and whether it fits our 8.2+ floor; whether legacy aesgcm support was dropped (affects any Safari/older-endpoint scope); whether the WebPush constructor, queueNotification/send/flush batch API, or report objects changed; and whether VAPID key format or loading changed (PEM vs. base64 DER), since that dictates our key-generation and custody tooling. The release notes do not answer any of this — it is a verification task, not a known quantity.
• Abstraction mismatch — unchanged. Adopting the bundle to configure a library we would then use directly creates two places to look and one more upgrade axis.
• VAPID key handling — unchanged, still the expensive-to-get-wrong area. A rotated or lost private key silently invalidates every subscription. Any wrapper must make custody explicit.
• Browser/push-service fragmentation — unchanged. Payload caps, TTL semantics, and Urgency still need per-endpoint-family testing, not just compilation.

Key questions for the maintainer/owner.

1. Does web-push-php v11 drop or deprecate anything we rely on — PHP floor, aesgcm, constructor/API signatures, VAPID key format — and is there an upgrade guide we can follow rather than reverse-engineer?
2. Does the newly documented HTTP-client customization let us inject a client with bounded concurrency and our standard timeout/retry/observability stack? If so, that is the integration seam we should build against.
3. Do we need the Symfony bundle at all, or does the Laravel-native notification channel (laravel-notification-channels/webpush) already wrap the same upstream library? Note that it too will need to track v11 — verify its v11 compatibility status before the spike, since a lagging channel pushes us back to a library wrapper.
4. Who owns VAPID key rotation, and where do keys live — .env, secret manager, DB? What is the re-subscription playbook?
5. What is expected fan-out (subscribers × sends/day), and does everything route through the queue?
6. Which endpoints/browsers are in scope — specifically Safari?
7. Does the app already have a service-worker/push client story? Server-side push without a registered service worker is dead code.

Integration Approach

Stack fit. Unchanged: Laravel 10/11, PHP 8.2+, MySQL/Postgres, Redis queues. The bundle does not fit; the library does. Recommended dependency is minishlink/web-push at v11.x, pinned, behind a first-party WebPushServiceProvider and a thin WebPushClient facade. Evaluate laravel-notification-channels/webpush first if the team prefers batteries-included — but only after confirming it supports web-push-php v11; a channel pinned to v10 is a reason to drop to the library, not a reason to hold the library back. The bundle's config surface (VAPID subject/public/private key, TTL, urgency, batch size) still maps 1:1 onto config/webpush.php, so nothing is lost by skipping it. Add one new config concern surfaced by v7.0.0: the HTTP client instance, with explicit concurrency cap, timeouts, and retry policy.

Migration path. Still greenfield — no schema or state to migrate. The v7.0.0 notes make the trap more concrete: if anyone has sketched against the bundle, port only the config semantics and the client-customization pattern, never the service definitions. The asymmetry argument for starting at the library layer is now stronger, not weaker: starting on the bundle means absorbing bundle v6→v7 and library v10→v11 and eventual Symfony majors; starting on the library means absorbing v11 once.

Compatibility. This is now the gating work item. Pin to v11, read the migration guide before writing code, and verify PHP support against our runtime. Confirm whether aes128gcm is the only supported encoding in v11 or whether aesgcm remains for legacy endpoints — this determines our Safari and older-browser scope, and getting it wrong shows up as failed sends per-endpoint, not as a build failure. Confirm the Authorization: vapid t=...,k=... header behaviour, since some push services are strict. Confirm the PSR-18 client injection point matches the client we intend to supply. If the Laravel notification channel is still on v10, treat that as a decision input, not a blocker.

Sequencing.

1. Read the web-push-php v11.0.0 migration guide and the bundle's HTTP-client doc page — one to two hours, and it de-risks everything downstream. Then run the half-day spike: notification channel (if v11-compatible) vs. thin library wrapper.
2. Add the pinned v11 dependency and config/webpush.php, including HTTP client settings; generate VAPID keys per environment (dev/staging/prod separated so a dev leak cannot forge prod pushes; private key never committed).
3. Schema: push_subscriptions (user_id, endpoint [unique, hash-indexed for length], p256dh, auth, user_agent, created_at, last_success_at, failure_count). Index on a hash, not the raw URL column, on MySQL.
4. Client-side: service-worker registration + pushManager.subscribe() + authenticated POST of the subscription. Critical-path dependency; do not sequence server work ahead of it.
5. Server-side: queued SendPushNotification job per subscription, batched with bounded concurrency through the injected HTTP client; Notification class or payload builder.
6. Feedback loop: delete on 404/410, backoff on 429/5xx, per-endpoint logging, wired into existing observability before broad enablement.
7. Roll out behind a flag to internal users, then a percentage of the active base.

Operational Impact

Maintenance. Low code surface, real ownership cost. The v7.0.0 release is a useful calibration point on what "maintenance" means here: the bundle's version number is dictated by an upstream major we would otherwise not have to think about, and a Laravel team ends up reading Symfony bundle release notes to learn about a PHP library. Staying on the library directly collapses that to a single dependency to track — which we would track anyway. Budget a recurring quarterly dependency review covering web-push-php releases and browser-push ecosystem changes; assume we may need to patch or fork, and keep the wrapper thin enough that we can.

Support. No vendor, no SLA, MIT. Internal expertise is the support model. The WebPushClient interface plus one implementation keeps a transport swap to roughly a day. Two runbooks are mandatory: VAPID key custody/rotation, and the v11 upgrade path, so a future major does not become an unplanned project. Document explicitly that the bundle is not in the dependency graph and why, so a future team does not re-litigate it.

Scaling. Unchanged shape: fan-out, one trigger to N third-party calls at 100ms–2s latency. Never synchronous in a request cycle. Queued jobs, chunked subscriptions, capped concurrency, push on its own queue so broadcasts do not starve other work. The v7.0.0 HTTP-client customization is the lever here — use it to set connection limits, timeouts, and retry/backoff at the client layer rather than in job code, and to attach instrumentation. Storage scales trivially (one row per device), but expect 5–15% monthly row churn from expiry and unsubscribes. Push remains best-effort; anything that must be received needs an in-app fallback.

Failure modes.

• Expired/invalid subscription (404/410) — most common; delete the row, never retry.
• Push service throttling (429) / outage (5xx) — exponential backoff with jitter, per-endpoint-host circuit breaker.
• VAPID key loss or rotation — highest severity, lowest frequency; every send 401/403s and every subscription is unrecoverable. Back up the private key with the same rigor as the app key.
• Upstream major-version breakage — newly promoted to a named failure mode. A v11 encoding, key-format, or API change can surface as silent per-endpoint send failures rather than a compile error. Mitigate with a staging smoke test against a real endpoint family on every dependency bump.
• Oversized payload — push services cap payloads (~4KB, less in places); enforce a size check at build time and send a tiny "wake and fetch" payload for anything large.
• Silent client-side failure — server sees success while the service worker is gone or permission revoked. Track last_success_at, prune, and re-prompt.
• Queue backlog during broadcasts — isolate onto a dedicated queue.

Ramp-up. Low for a Laravel developer: the library API is small, and the conceptual load sits in the browser-side model (service workers, VAPID, subscription lifecycle), not the PHP. 1–2 days to a working end-to-end staging path, plus 2–3 days for feedback loop, pruning, and observability — with the frontend service-worker work likely the long pole. Add a half-day up front for v11 migration-guide reading and a staging smoke test. The bundle specifically remains negative ramp-up: a Laravel developer would learn Symfony DI conventions to configure a library they then use directly.

Bottom line. v7.0.0 confirms rather than changes the verdict. It shows the bundle is maintained and that its versioning is chained to web-push-php majors — an argument for depending on the library directly and skipping the Symfony layer. Recommend against the bundle; evaluate web-push-php v11 directly, or the Laravel notification channel if it is already v11-compatible, with the compatibility check and HTTP-client injection point as the first tasks. Low risk, low reward, cheap to reverse.