Filament Fcm Driver Laravel Package

Technical Evaluation

Architecture fit. The package is a thin adapter: a Filament plugin that binds tomatophp/filament-alerts to the laravel-notification-channels/fcm driver, adds an admin surface for the Firebase service account key, and generates the web service worker. That is a sensible fit for panels already standardised on filament-alerts — it is an add-on, not a new subsystem. It does presuppose a modern floor (Filament v5, Laravel 12/13), so it is only viable if the host app is on that line.

Integration feasibility. Composer install is straightforward; the real risk is transitive resolution. v5.0.0 explicitly removes the lcobucci/jwt 4.x lock-in by widening the FCM channel to ^5.0 || ^6.0 — that was a hard install blocker and removing it materially improves adoptability. But ^5.0 requires filament-alerts ^5.0, so this cannot be adopted in isolation: you take the Filament v5 line or you stay on the v4 branch. It is a coupled upgrade, not a drop-in.

Technical risk.

• Credential handling. Storing the service account key on the private local disk is the right direction, and old keys keep working (no forced re-upload — good migration ergonomics). But it remains a long-lived JSON private key on app-local disk: no mention of rotation, per-environment separation, encryption at rest, or secret-manager/KMS support.
• Fan-out. "Public notifications are sent to every user with an FCM token" implies an unbounded recipient set. With no documented batching or rate limiting, this is a thundering-herd risk against FCM project quotas and queue depth.
• Queue semantics. Single-user notifications are queued on filament-alerts.queue "again" — the "again" flags a regression. Queue-name coupling means workers must be provisioned for that exact queue or sends silently stall.
• Service worker lifecycle. Generated by an artisan command; unclear whether regeneration is needed per release, whether it is fingerprinted for cache busting, or how it behaves behind a CDN.
• Port stability. "Push notification actions work again on Filament v5" is a second regression-fix marker — the v5 port has had rough edges.
• Bus factor. Effectively single-maintainer with community PRs, now supporting two branches, which doubles surface area.

Key questions.

1. Is the credential storage path configurable (S3/secret manager) or hardcoded to the private local disk, and is rotation documented?
2. Is the public fan-out chunked/batched, with rate limiting or FCM quota backoff?
3. Is filament-alerts.queue configurable, and what is the retry/backoff policy on failure?
4. Are stale tokens pruned automatically on UNREGISTERED / INVALID_ARGUMENT responses?
5. What is the automated test coverage, particularly for the Filament v5 actions and the install command?
6. Is service worker generation idempotent and cache-busted per release?
7. Single Firebase project only, or multi-tenant / multi-app credentials?
8. What is the committed support window for the v4 branch?

Integration Approach

Stack fit. Laravel 12 with a Filament v5 panel, filament-alerts ^5.0, and an FCM-enabled notification channel. Treat the Laravel 13 claim as forward-looking and validate against your actual pinned framework. On Filament v4 this release is not applicable — pin the v4 branch and plan the v5 move separately.

Migration path. Two distinct routes. (a) New adoption on Filament v5: install, run php artisan filament-fcm-driver:install, upload the service account key via the panel, provision a worker for filament-alerts.queue, confirm the service worker is served over HTTPS at the correct scope. (b) Upgrade from v4: the blocking step is the Filament v4→v5 and filament-alerts ^4→^5 upgrade — do that first in a branch, then bump this package. Existing keys keep working, so no re-upload is needed, but confirm the key file has moved out of legacy/public storage into the private disk.

Compatibility. Verify no other dependency pins lcobucci/jwt below what FCM ^6 allows — the fix helps, but a competing constraint can still flip resolution. Check the PHP floor against your CI matrix.

Sequencing.

1. Branch bump of Filament + filament-alerts; green CI.
2. Add this package, run the install command, diff published config and service worker.
3. Staging: exercise a single-user queued notification, a public broadcast, and the Filament v5 action.
4. Provision and verify the filament-alerts.queue worker.
5. Load-test the public broadcast at realistic user counts against a non-prod Firebase project.
6. Roll out behind a feature flag; retain the v4 branch as rollback.

Operational Impact

Maintenance. Two live branches is a positive signal of care but means you must track which line you are on. A small maintainer base means a fork-ready posture for the credential and fan-out code paths is prudent.

Support. Firebase project ownership, service account key custody, and VAPID/web-push setup become your team's responsibility — the package handles plumbing, not governance. Private-disk storage is an improvement but shifts backup obligations to you: exclude the key path from broad backups or encrypt the volume.

Scaling. Fan-out to "every user with an FCM token" is the primary scale risk — cost and duration scale with token count per broadcast, and FCM project quotas bound throughput. Workers on filament-alerts.queue become a dedicated capacity line item; size them and alert on backlog depth.

Failure modes. Expired/unregistered tokens failing silently without pruning; queue backlog or a misnamed worker (notifications enqueue but never send); stale service worker after deploy (push arrives, click handler broken); missing or renamed key file after a disk change; key leakage via backup or build artifact.

Ramp-up. A Laravel developer reaches a first notification in under a day. The non-trivial learning is Firebase console setup (service account, web push credentials, service worker scope) and queue operations. If coming from v4, budget a separate spike for the Filament v5 upgrade — that, not this package, dominates the effort.