Laravel Fcm Laravel Package

Product Decisions This Supports

• Push notification delivery as a commodity feature, not a differentiator — this package answers "can we ship push to Android/web in a sprint without building an FCM client?" That's a build-vs-buy call, and here the "buy" is free (MIT), which lowers the bar further.
• Roadmap sequencing for engagement surfaces — if push notifications gate re-engagement, transactional alerts, or a "notify me when X" feature, a drop-in Laravel service provider lets you prototype the user-facing loop (notification preferences, payload design, deep-link routing) before committing to a hardened delivery layer.
• Multi-channel notification architecture — evaluates whether push lives behind Laravel's Notification facade or a bespoke service. The package's FCM-only scope forces an explicit answer: is push a first-class channel or a leaf node?
• Lumen microservice decisions — the Laravel and Lumen support is the one genuinely strategic detail. If you're running a small notification-dispatch service separate from the monolith, this is a candidate for that boundary.
• Vendor lock-in scoring — FCM is Google-operated; the package is a thin wrapper. The decision it informs is not "which wrapper" but "how much of our notification logic is allowed to be Google-shaped."

The decision it should actually trigger: this package is archived and its target API (FCM HTTP Legacy) was shut down by Google in June 2024. Any roadmap item that assumes it as a dependency is a decision to not ship push, and should be re-scoped to the HTTP v1 API — via kreait/firebase-php, laravel-notification-channels/fcm, or a direct Google client. Treat it as a reference implementation to read, not a dependency to adopt.

When to Consider This Package

Consider it only under narrow, mostly historical conditions:

• You are on PHP 7.x / Laravel 6–8 / Lumen, on a frozen or legacy branch, and need to touch an existing integration you already own.
• You need to read or port a working example of FCM payload construction, topic vs. device-token targeting, and Laravel service-provider/config-publishing conventions — the code is small and legible enough to serve as a design reference.
• You are doing throwaway prototyping in a sandbox where the legacy endpoint is mocked and nothing reaches production.

Look elsewhere — decisively — when:

• Anything is going to production. The underlying legacy FCM endpoint is retired; the package will not deliver.
• You need APNs, Web Push, or notification-channel abstraction, which this does not provide.
• You need maintained security posture. No releases since October 2022, archived upstream, no CVE response. That fails almost any dependency-review gate.
• You need HTTP v1 OAuth2 service-account auth — the modern FCM contract. This package does not implement it.
• You need batching, retry/backoff, delivery receipts, or analytics — all absent.

Recommendation: reject for adoption, retain as reference. The 62-star count and 1.06 score are consistent with a package that was adequate for its moment and is now a liability.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a free Laravel package for push notifications. It would have saved us perhaps one to two engineering weeks of integration work, but it is archived and built against a Google API that was switched off in mid-2024 — so it cannot deliver a notification today. The cost of adopting it is not license fees, it's an outage plus a forced rewrite under deadline. I recommend we budget the small additional effort for a maintained FCM HTTP v1 client instead; the delta is measured in days, and it removes a known-dead dependency from our stack.

To engineering (short): Skipping apility/laravel-fcm. Archived since 2022, targets the retired FCM legacy HTTP API, no maintained successor path in-repo. It's still useful as a ~500-line reference for payload shape and service-provider wiring; read it, don't install it. Proposed replacements, in order of preference: kreait/laravel-firebase (official-adjacent, HTTP v1, actively maintained) or laravel-notification-channels/fcm if we want push to sit alongside mail/database/SMS in the Notification facade. Both require service-account credentials and OAuth2 token handling, which is the real integration work the original package was hiding from us — worth stating plainly in the estimate rather than discovering it mid-sprint.