Filament Browser Notifications Laravel Package

Technical Evaluation

Architecture fit. The package is well-suited to the shape of a Filament-heavy Laravel application. It attaches to Laravel's DatabaseNotification::created Eloquent event, so it exploits a framework lifecycle point that every existing notification already crosses — no per-notification wiring, no channel registration, no service worker publishing. Delivery is deferred to a queued job, which keeps the request path (and the notification write) decoupled from push latency and provider failures. VAPID-only is a meaningful architectural simplification: no Firebase dependency, no third-party WebSocket infrastructure, no new secrets beyond a key pair. The design is genuinely "zero-config by default, opt-out when needed," which is the correct posture for an internal admin tool where notification fatigue is the primary adoption risk.

Integration feasibility. Installation is a single artisan command that generates VAPID keys, runs the push_subscriptions migration, injects the HasPushSubscriptions trait into User, and auto-registers the plugin across all Filament panels. The one thing a TPM must flag: the installer writes to your app/Models/User.php source file. That is convenient and auditable (it degrades gracefully to printed manual instructions when the file is read-only, per 1.1.1), but it is an inherently fragile operation — the 1.1.1 changelog shows exactly this class of bug (trait imported but not applied when Notifiable sat alongside other traits). Plan to verify the trait is actually on the class body in a staged environment, not just trust the exit code.

Technical risk.

• Implicit global behaviour. A listener on DatabaseNotification::created fires for every database notification in the app, including ones outside the Filament panel. Throttling (5s default grouping) and silent via ->viewData(['silent' => true]) are the only escape hatches, and the silent path itself required a v5 fix and a non-obvious viewData() workaround. Expect to audit existing notification classes and mark noisy ones silent.
• Low external signal. 15 stars, 0 dependents, single-maintainer consultancy (Emuniq). There is no ecosystem to lean on; the README, changelog, and two versions of tests (8 tests for listener/throttle/silent/URL extraction, plus Pest coverage of the trait patcher from 1.1.1) are the entire quality surface.
• Filament version sprawl. Supporting Filament 3, 4, and 5 is generous but multiplies the internal compatibility matrix — colour conversion to hex across v3/v4/v5 oklch() handling, ActionGroup resolution, and openUrlInNewTab respect are all version-sensitive heuristics that have already needed point fixes.
• iOS reality check. Push on iOS requires Add-to-Home-Screen. The plugin detects and guides, but it is UX friction you cannot remove. Users who don't install the PWA will silently receive nothing.
• Preconditions are non-trivial. HTTPS and a running queue worker are hard requirements; neither is the package's problem to solve, and both are common causes of "it doesn't work."

Key questions to take to the maintainer / internal review.

• Exactly which parts of Filament's notification payload does the URL extraction read, and how does it behave on custom actions, modals, and multi-panel setups?
• What is the failure logging and retry story for the queued job — are webpush errors surfaced (410 is auto-cleaned, but what about 401/403/network)?
• Is there a documented way to disable the listener per panel or per notification class beyond silent?
• How are VAPID keys stored and rotated, and what happens on rotation to existing subscriptions?
• What is the intended upgrade contract if Filament 6 changes the notification internals the listener relies on?

Integration Approach

Stack fit. Laravel 10+, PHP 8.1+, Filament 3+, plus laravel-notification-channels/webpush underneath. This is a clean fit for any team already running a Filament panel with sendToDatabase() in production. Teams without a queue worker, or on HTTP-only internal deployments, are not a fit until those are resolved.

Migration path. Additive and reversible. The only schema change is push_subscriptions; the only code change is a trait on User plus optional config publishing. No existing notification classes need editing. Rollback is removing the package and the trait — dead subscriptions simply stop being used.

Compatibility. Confirm your exact Filament minor (v3 vs v4 vs v5) and your PHP/Laravel versions against the requirements block. Test in staging across the panels you intend to enable, because auto-registration applies to all panels by default — if you have separate admin and customer-facing panels, verify the prompt and profile section behave sensibly on each (config override in PanelProvider is the lever here).

Sequencing.

1. Spike in staging on a throwaway user: install, verify browser-notifications:test {id} --sync reaches a real browser.
2. Confirm prerequisites: HTTPS everywhere in scope, queue worker healthy, Horizon/queue:work monitored.
3. Verify the trait patch landed in User.php; add manually if the installer skipped it.
4. Publish config and pin queue_connection/queue_name to your operational queues — do not leave it on default in a busy system.
5. Audit existing database notifications and annotate noisy ones silent before enabling the prompt.
6. Roll to internal staff (opt-in prompt keeps this low-risk), observe subscription counts and 410 cleanups, then widen.
7. Document the iOS Add-to-Home-Screen flow in your own onboarding docs; the plugin guides users but your support team should know it too.

Operational Impact

Maintenance. The upstream cadence is active (v1.0 → v1.2 with meaningful fixes in a short window) but entirely dependent on one consultancy. Treat this as a small, fork-friendly dependency: read the source before adopting, and budget for the possibility of in-housing maintenance if the project stalls. MIT license makes that legally trivial. Keep an eye on the underlying webpush channel package — that is the real operational dependency and the more likely source of breakage.

Support. No SLA, no dependents, GitHub issues only. Your support surface is: prompt appearing/not appearing, push not arriving (invariably queue or HTTPS), and iOS users not receiving anything (PWA not installed). The test command and profile section status/device count are good first-line diagnostics — put those in your runbook.

Scaling. Each database notification triggers one queued job; the throttle groups bursts within the configured window so a notification storm becomes one "You have N new notifications" push rather than N. Set throttle_seconds to 0 only if you genuinely want one push per notification. Subscription rows grow with devices per user; 410 Gone cleanup keeps the table honest. Push fan-out ultimately hits the browser vendors' push services (FCM, APNs, Mozilla), so volume is bounded by device count, not by your infrastructure.

Failure modes to instrument.

• Queue down → notification writes succeed, push silently deferred or never sent. Alert on queue depth.
• Missing/rotated VAPID keys → pushes fail without user-visible error. Store keys in your secret manager, not just .env, and test after any rotation.
• Installer partial success in Docker → trait imported but not applied, BadMethodCallException at runtime. Fixed in 1.1.1, but verify on every fresh container build.
• iOS Safari outside PWA → no push, user confusion. The profile section's guidance mitigates but does not eliminate this.
• Complex action URLs → fallback to panel path rather than the intended deep link. 1.2.0 fixed ActionGroup and removed hardcoded /admin, but this heuristic remains the most likely source of "wrong page opened" feedback.
• Throttle misconfiguration → either notification spam (throttle_seconds: 0) or lost individual context (grouped pushes).

Ramp-up. Low for engineers — one install command, one test command, one config file. The real ramp-up cost is operational literacy: understanding the service worker route, the auto-generated manifest.json, the iOS PWA flow, and where the listener fires. Half a day of reading the source pays for itself the first time someone asks "why did this notification push and that one didn't?"