Fcm Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for push notifications: Informs whether to wrap Firebase Cloud Messaging in-house or adopt a thin Laravel integration, weighing maintenance cost against the ~1–2 days of custom HTTP v1 client work plus credential handling, retry logic, and token management.
• Platform/channel roadmap: Shapes how quickly push can be added as a notification channel alongside email/SMS in an existing Laravel notification stack, and whether push is a v1 launch feature or a fast-follow.
• Mobile companion strategy: Signals whether a native mobile app (iOS/Android) is viable on the current backend, since FCM is the default transport for both platforms and the package determines the integration surface area.
• Upgrade planning / technical debt budget: The 1.x → 2.x major-version jump is a forcing function to schedule migration work, re-test notification flows, and confirm credential and configuration changes before the next release cycle.
• Vendor concentration risk: Supports a decision on how tightly to couple the product to Firebase (Google) for messaging versus keeping an abstraction layer that allows swapping providers later.

When to Consider This Package

• Adopt when: The product is Laravel-based, push delivery targets both iOS and Android, and the team wants FCM behind a familiar Laravel service provider/config/facade rather than hand-rolling Google's HTTP v1 API, OAuth2 token refresh, and service-account JSON handling.
• Adopt when: Push volume is modest-to-moderate, targeting is mostly topic- or device-token-based, and the team accepts Firebase Console as the operational surface for campaigns and analytics.
• Look elsewhere when: You need a packaged marketing-automation layer (journeys, in-app messaging, A/B testing, rich segmentation) — that's a Braze/OneSignal/CleverTap-class decision, not a transport wrapper.
• Look elsewhere when: You are not on Laravel, need a framework-agnostic SDK, or require vendor-managed deliverability SLAs and support contracts.
• Exercise caution when: The project is on an older Laravel or PHP version, or has a large existing 1.x integration — a major version bump almost certainly carries breaking configuration and API changes (commonly credential format, payload builder, and minimum framework versions) that must be scoped before committing.

How to Pitch It (Stakeholders)

For executives: Firebase Cloud Messaging is the industry-standard, zero-cost transport for mobile push on both iOS and Android. This package is a thin Laravel adapter that lets our existing backend team ship push notifications without building and maintaining a custom Google API client. The trade-off is coupling to Google's platform and a modest amount of integration work — not a strategic lock-in, since push payloads are simple to re-point to another provider later if requirements grow.

For engineering: This is a community Laravel wrapper around FCM's HTTP v1 API. It removes boilerplate — service account auth, OAuth token refresh, message construction, topic/device targeting — behind Laravel-native config and a facade. Important: v2.0.0 is a major release and the published notes are only a changelog link, so the first task is to read the full diff for breaking changes before adopting or upgrading. Expect changes to configuration keys, credential handling, minimum PHP/Laravel versions, and possibly the send API surface. Treat the upgrade as a scoped ticket with regression tests around every notification path, not a composer update. If we adopt, we should pin the version, wrap the facade behind our own notification service so we aren't calling it from dozens of call sites, and document the service-account rotation procedure — that keeps a future provider swap or another major bump cheap.