Fcm Laravel Package

Product Decisions This Supports

• Channel expansion: do we add push, and when? Push is one of the highest-leverage retention surfaces for mobile products (order status, transactional alerts, re-engagement). This package is the smallest credible path from "we have a Laravel app" to "we ship push notifications," so it directly informs whether push lands in this quarter's roadmap or next. Release 6.0.0 widens the addressable use cases: with FcmTopicChannel, one event can now reach a whole topic-subscribed audience, not just individual devices.
• Build vs. buy (vs. adopt). The alternative is hand-rolling an FCM HTTP v1 client: credential handling, payload shaping per platform, token refresh/cleanup, error-code mapping, retry behavior. This package collapses that into a channel class plus a toFcm() method on existing notification classes — and 6.0.0 shrinks the remaining gap further with android() and ios() helpers on the message class, so platform-specific payload shaping is now a fluent call rather than nested arrays. Typical delta is a couple of engineer-days plus permanent maintenance surface — a clear "adopt" unless we have unusual requirements.
• Vendor strategy: FCM-first vs. a push SaaS. Because the package binds us to Firebase/Google but not to a paid orchestration vendor, it supports a staged decision: ship push cheaply now via FCM, defer a Braze/OneSignal/Airship decision until we actually need journeys, A/B testing, or cross-channel campaign tooling. Topic support materially extends how long "FCM-first" stays viable — lightweight segment broadcast (product announcements, per-region or per-plan alerts) no longer forces an early SaaS purchase. That keeps optionality and avoids a contract signed before we know our messaging needs.
• Scope boundary setting. This package delivers messages; it does not segment audiences, schedule campaigns, run experiments, or report engagement. Topics are a subscription mechanism, not an audience builder — no rules, no computed segments, no send-time optimization. Explicitly deciding "delivery now, orchestration later" prevents scope creep in the push epic and sets expectations with marketing stakeholders who may hear "topics" and assume campaign tooling.
• Notification routing policy. It plugs into Laravel's native notification abstraction, so the same event can fan out to mail, database, and push with per-user preferences. That makes "which events deserve a push vs. an email vs. in-app only" — and "which are per-user vs. topic broadcast" — a product-configuration decision rather than an engineering one.
• Platform upgrade forcing function. 6.0.0 requires PHP 8.4+ and Laravel 12+. That converts a routine dependency bump into a roadmap dependency: if our app is on Laravel 10/11 or PHP 8.2/8.3, adopting the current major means scheduling the framework/PHP upgrade, or pinning an older 5.x line and accepting it as legacy from day one. That trade-off belongs in the planning conversation, not in a sprint.
• Cost model inputs. FCM itself is free at effectively any volume we'd reach, and the package is MIT. The real line item is engineering time plus queue worker capacity — a materially different (and smaller) budget conversation than a per-subscriber SaaS quote. Topic fan-out changes queue sizing math: one queued job can reach an arbitrarily large audience, so throughput planning shifts from "per event" to "per broadcast."
• Operational ownership decisions. Adoption forces us to own device-token lifecycle (a devices table, pruning on uninstall/token rotation), topic subscription lifecycle (subscribe/unsubscribe on preference change or logout — stale subscriptions are a silent correctness bug), credential rotation for the service account, and delivery observability. These are decisions to make consciously, not discover in production.

When to Consider This Package

Good fit when:

• The backend is Laravel 12+ on PHP 8.4+ (the package targets the framework's Notification channel contract and 6.x now requires these floors), and we have at least one Firebase-registered client — Android, iOS via FCM, or web push.
• We already use, or intend to use, Laravel notifications for email/database — adoption is then additive, not a new subsystem.
• Our push needs are transactional and targetable by token or topic: order updates, alerts, reminders, per-user messages, and occasional broadcast/announcement sends to a topic-subscribed audience. FcmTopicChannel plus the android()/ios() helpers cover this cleanly.
• We have (or will have) queue workers, since push sends — especially topic broadcasts — should be queued and retried rather than fired inline in a request.
• We want to avoid a push SaaS contract and the associated data-processing agreements, per-subscriber pricing, and vendor SDKs in the app.
• We can absorb a major-version cadence: 6.0.0 is a breaking release, so plan for an upgrade path and read the changelog/upgrade notes rather than assuming the listed items are the whole story.

Look elsewhere when:

• Marketing-grade messaging is the requirement: visual campaign builders, user journeys, send-time optimization, A/B testing, rich engagement analytics, in-app messaging, or cross-channel orchestration. That is Braze / OneSignal / Airship / Iterable territory; topic support here is not a substitute, and the package shouldn't be stretched to try.
• We are not yet on Laravel 12 / PHP 8.4 and cannot move this quarter — adopting 6.x implies an upgrade project; adopting an older pinned major means owning a version we'll need to migrate off shortly.
• We need direct APNs or self-hosted Web Push (VAPID) without a Google dependency, or operate under data-residency constraints that preclude Firebase.
• The backend isn't Laravel/PHP.
• We require a commercial SLA, indemnity, or vendor support line. This is community-maintained MIT software: no warranty, and support depends on maintainer responsiveness and community attention.
• Diligence flags matter to us: verify real adoption via Packagist download trends and the health of the broader laravel-notification-channels org rather than relying on star count alone — the dependents figure in this dataset reads as an undercount and should not be treated as a signal either way.

How to Pitch It (Stakeholders)

To executives — one paragraph: Push notifications are a proven retention and transactional-communication channel, and we can add them for roughly a couple of engineer-days rather than a build project. This is a free, MIT-licensed, actively maintained package (version 6.0.0, part of the well-known laravel-notification-channels organization) that connects our existing Laravel notification system to Firebase Cloud Messaging — which is itself free at our expected volume. The new release adds topic-based sends, so we can reach an opted-in audience with a single job for announcements and segment alerts, not just one-to-one messages — which means we can defer a paid orchestration platform longer. No new vendor contract, no per-subscriber fee, no SDK sprawl. The one caveat is that 6.0.0 requires PHP 8.4+ and Laravel 12+, so this pairs with an upgrade we may already have on the roadmap; if we're behind, we either schedule the bump or run an older pinned major short-term.

To engineering — the mechanics: It implements Laravel's native notification channel contract, so push becomes another via() entry alongside mail and database, with a toFcm() payload method; the new FcmTopicChannel adds topic-addressed sends, and android()/ios() helpers remove most manual per-platform payload assembly. Sends are queueable and testable through the standard notification fakes. The work is not the integration — it's the surrounding plumbing we'd own regardless: a device-token table with pruning on rotation/uninstall, topic subscription bookkeeping tied to user preferences and logout, service-account credential management and rotation, queue capacity planning that accounts for topic fan-out, and delivery logging so we can see failures. Those are the real estimate drivers. Note this is a major version: check the changelog for breaking changes beyond the PHP/Laravel floor bump before we plan the upgrade, and run Pint formatting separately so it doesn't pollute the integration diff.

The ask: Approve a short spike — integrate the channel, ship one transactional notification end-to-end to a device plus one topic broadcast, and instrument delivery success/failure. That gives us a defensible effort estimate and a working slice before we commit push to the roadmap.