Laravel Webpush Kit Laravel Package

Technical Evaluation

Architecture fit. This is the browser half that laravel-notification-channels/webpush deliberately left to the application: subscription button, service worker, subscription routes, and iOS Home Screen plumbing. It is Laravel-native rather than a JavaScript SDK wrapper — a Blade component, an artisan command, publishable assets, an about entry — which means it inherits your existing auth, routing, and asset pipeline instead of introducing a parallel front-end stack. Critically, it does not create a second source of truth for subscriptions: the routes delegate to the channel's own updatePushSubscription() / deletePushSubscription(). That is the single most important architectural property here and it is satisfied.

Integration feasibility. Low-to-moderate. composer require, publish the service worker (or import it into an existing one), drop <x-webpush-kit::head /> and <x-webpush-kit::button /> onto a page, reuse the VAPID keys the channel already requires. No new infrastructure, no new credentials, no queue or scheduler changes.

Technical risk.

Key questions.

• Is Livewire a hard dependency, or does the button work in a Blade-only app? The test matrix used Livewire 4; the requirement isn't stated.
• What is the service worker update strategy (skipWaiting / clients.claim)? Stale workers are the most common "push stopped working" cause.
• Are the subscription routes registered with configurable middleware, and is the endpoint validated against the authenticated user?
• Can the two-step prompt copy and styling be overridden without forking the component?
• Is there a stated support window and a maintainer commitment to a 1.0, or is this a single-maintainer package we would be betting a user-facing channel on?
• What is the fallback contract when webpush-kit:subscribed fires but the server-side save fails?

Integration Approach

Stack fit. Laravel 12/13, PHP 8.3+, channel v11–13. Fits if your app is already on the channel — this is an additive front-end layer, not a replacement. If you are not already sending web push server-side, this package is not the entry point; adopt the channel first.

Migration path.

• No existing service worker: publish /webpush-sw.js, register as-is. Simplest path.
• Existing service worker: use the import mode and keep your current worker as the single registered scope. Verify push handlers and pushsubscriptionchange survive the merge.
• Existing custom subscribe button: replace it, but read webpush-kit:subscribed / webpush-kit:unsubscribed into your existing analytics first so you don't lose instrumentation continuity.

Compatibility. Chrome/Edge desktop verified against Google's push service, including a real 410 dead-endpoint path. Firefox, Safari macOS, and iOS Home Screen are unverified. iOS additionally requires 16.4+ and Add to Home Screen — the component surfaces this state, but the degradation path has not been exercised.

Sequencing.

1. Spike in a throwaway branch: install, publish the worker, run php artisan push:test against a staging device.
2. Resolve service worker scope against your current registration. Do not skip this.
3. Security review of the shipped routes — middleware, CSRF, ownership check on delete.
4. Put the button behind a feature flag on one low-traffic surface.
5. Wire the browser events into analytics before enabling broadly.
6. Manual device matrix: Chrome desktop, Chrome Android, Firefox desktop and Android, Safari macOS, iOS Home Screen. Block GA on this.
7. Wider rollout.

Operational Impact

Maintenance. Pre-1.0 means you own upgrade churn: pin the exact version, read every changelog, and budget for breaking changes on each 0.x bump. You also inherit the channel's version coupling and the PHP 8.3 / Laravel 12 floor, which will gate your own upgrade calendar rather than the reverse.

Support. php artisan push:test and the about entry are genuine support-cost reducers — they turn "push is broken" into a per-service answer (including 404/410 dead subscriptions and the Safari VAPID_SUBJECT rejection) in one command instead of a log dive. Offset against that: the untested browsers mean first-line support will field Firefox and Safari tickets with no verified baseline to compare against.

Scaling. The package adds no server-side fan-out; delivery scales with the channel and the push services. The routes do a per-request database write, and pushsubscriptionchange can trigger re-subscribe churn — rate-limit the endpoints and watch write volume on large subscriber bases.

Failure modes to expect.

• Dead endpoints (404/410) — handled by the channel, surfaced by push:test.
• Safari rejecting a malformed VAPID_SUBJECT — warned about, but a config error that fails silently on other browsers.
• Service worker scope conflict or duplicate registration — silent, no push at all.
• Stale service worker after deploy — intermittent delivery failures.
• Permission permanently blocked — unrecoverable from your UI; user must reset in browser settings.
• Insecure context (http, non-localhost) — no push; component shows an unsupported state.
• iOS without Add to Home Screen — no push.
• Notification click — unverified, and it is the behavior users judge the feature by.

Ramp-up. Low for a Laravel team: one component, one command, one publishable asset. The real cost is not learning the API, it is owning browser-permission UX and service worker lifecycle — assign a named owner for that, because it is where the incidents will come from.

Recommendation. Adopt for a flagged pilot to validate the untested paths, not as a GA dependency at 0.1.0. Promote to GA once notification click, Firefox, Safari macOS, and iOS Home Screen are verified — or once the package reaches 1.0 with a stated support window.