Larafirebase Laravel Package

Product Decisions This Supports

• Build vs. buy for push delivery: This package is the "buy (free)" option for server-side Firebase Cloud Messaging (FCM) in a Laravel codebase. It answers the recurring question of whether to hand-roll FCM HTTP v1 calls, credential handling, and payload shaping, or adopt a thin wrapper. Choosing it removes roughly a sprint of plumbing and ongoing API-drift maintenance from your roadmap.
• Framework upgrade planning: Release 1.3.9 explicitly adds Laravel 11.x, 12, and 13 support. This is the single most decision-relevant fact in the release — it means the package is not a blocker on a Laravel upgrade path through the next two major versions. If push notifications are on your critical path, this de-risks the upgrade.
• Scope of notification roadmap: The release is compatibility-only. No new features, no new providers, no delivery analytics. That confirms the product's shape: transactional push (device tokens, topics, data payloads) — not a campaign/segmentation/analytics platform. Plan your notification roadmap accordingly; marketing-grade features would require a different vendor.
• Platform coverage decisions: FCM routes to Android, web, and iOS (via APNs through Firebase). If your roadmap includes iOS, this package works only insofar as FCM's APNs bridge meets your reliability and payload needs. If iOS is a first-class surface with strict delivery requirements, this is a constraint to price into the decision, not a solved problem.
• Vendor concentration risk: Adoption deepens reliance on Firebase/GCP. That is acceptable if Firebase is already in the stack (Auth, Analytics, Crashlytics); it is a meaningful new dependency if it is not.
• Maintenance signal for the dependency register: Four separate community PRs across four Laravel majors, including first-time contributors, indicates an alive-but-volunteer project. Useful input for your "acceptable OSS dependencies" policy and for deciding whether to wrap it behind your own notification interface.

When to Consider This Package

Adopt when:

• You are on Laravel 10–13 and need straightforward server-triggered push: order updates, transactional alerts, device- and topic-targeted sends.
• Firebase is already your mobile backend (credentials, project, and device-token capture already exist).
• Your team is small and the alternative is writing and maintaining FCM HTTP v1 client code plus credential rotation yourself.
• You want the integration behind a Laravel Facade and config file rather than bespoke service classes.
• You are willing to wrap it in your own NotificationSender interface so the underlying transport stays swappable.

Look elsewhere when:

• You need direct APNs, rich media, delivery receipts, open-rate analytics, or campaign scheduling — evaluate OneSignal, Pusher Beams, or a direct FCM/APNs integration with a dedicated service.
• You need high-throughput batching or multi-tenant fan-out with per-tenant credentials at scale; verify performance and connection handling before committing.
• You require vendor SLAs or a commercial support contract; this is community-maintained OSS.
• Your compliance posture demands a documented, audited dependency with a published security policy and predictable release cadence — the 1.3.x version line jumping four Laravel majors at once suggests feature velocity is low even as compatibility is maintained.
• You are on a Laravel version outside 10–13, or on PHP versions the release does not confirm.

Prerequisites before committing: confirm the package's FCM API generation (legacy vs. HTTP v1), verify PHP version constraints against your runtime, and validate that token refresh/invalid-token handling matches your expectations — none of which this release note addresses.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source Laravel package for sending push notifications through Firebase. The new 1.3.9 release is a maintenance update that adds support for Laravel 11, 12, and 13 — the practical takeaway is that adopting it will not block our framework upgrade path for the next two major versions. It is low-cost and low-commitment, but it is a volunteer-maintained project with no vendor support and no analytics features. Recommendation: adopt for transactional push if Firebase is already in our stack, and treat it as an implementation detail behind our own interface rather than a strategic platform choice.

To engineering: Version 1.3.9 is compatibility-only — Laravel 11/12/13 support landed via four community PRs, including two first-time contributors. No API changes, no deprecations, no new features, so upgrade risk from 1.3.8 is negligible. Treat it as a transport, not a framework: define an internal notification interface so we can swap to direct FCM HTTP v1 or a commercial provider without touching call sites. Confirm our PHP version and FCM API generation (legacy vs. v1) before wiring it in, and add invalid-token cleanup to our own code — we should not assume the package handles token lifecycle for us.