Weave Code
Firebase Cloud Messaging Bundle Laravel Package
fresh/firebase-cloud-messaging-bundle
Fresh/FirebaseCloudMessagingBundle integrates Firebase Cloud Messaging into Symfony applications, providing configuration and services to send push notifications to Android, iOS, and web clients through FCM.
Provides integration with Firebase Cloud Messaging API.
Frequently asked questions about Firebase Cloud Messaging Bundle
- Is fresh/firebase-cloud-messaging-bundle a Laravel package?
- No. It is a Symfony bundle that registers a Bundle class and service definitions through Symfony's DependencyInjection and HttpKernel lifecycle. Laravel has no bundle registration concept, so there is no supported way to install and configure it as you would a Laravel package. Using it inside Laravel means manually instantiating its internal sender service, at which point the bundle adds no value over a small HTTP client of your own.
- Does this bundle use the FCM HTTP v1 API or the legacy server key API?
- You must verify this before committing any engineering time, because it is a hard go/no-go. Google shut down the legacy FCM endpoint that accepted a static server key in June 2024, so any package still targeting it cannot deliver notifications today. HTTP v1 requires OAuth2 service account token acquisition and refresh via google/auth, which an old, unmaintained wrapper is unlikely to implement correctly. Check the source for the request URL and token handling before anything else.
- Will composer require resolve in a Laravel 10 or 11 application?
- Probably not, and you should test it the same day you evaluate the package. Laravel pins specific Symfony component majors such as http-foundation, http-kernel, console, and process, and a bundle built against a different Symfony major will produce a dependency conflict before you write a line of code. A package of this vintage may also be constrained to PHP 7.x and Symfony 3, 4, or 5, which collides with the PHP 8.1+ baseline for Laravel 10 and 11. Treat a clean composer resolve as a required gate, not a later surprise.
- What should I use to send Firebase push notifications from Laravel instead?
- The practical options are kreait/firebase-php, laravel-notification-channels/fcm, or a thin client built on google/auth plus Guzzle that calls the HTTP v1 endpoint directly. All of these plug into Laravel's notification channels and queue system, giving you retries, rate limiting, and per-user routing for free. Dispatching inside queued jobs also keeps slow network calls out of your request cycle.
- How is this bundle installed and configured in a Symfony application?
- You install it with Composer and register the bundle in your kernel, then supply credentials and project settings through the bundle configuration tree. From there the bundle's services handle authentication, payload construction, and device-token targeting so you do not write raw HTTP client code. None of that wiring is reusable in Laravel, which is the core problem with adopting it here.
- Can it send to topics and batches of device tokens?
- The package advertises single-device, topic, and token-batch sending along with notification and data payloads and custom options. Whether that surface is complete enough is a separate question: confirm it covers notification versus data-only messages, topic and condition targeting, Android, APNs, and WebPush platform overrides, and multicast batch sends. Missing any of those means you are patching the wrapper rather than using it.
- Does it handle invalid or unregistered device tokens?
- There is no documented evidence that it does, so assume you will implement token lifecycle handling yourself. A production FCM client must inspect error responses for UNREGISTERED and INVALID_ARGUMENT and prune the corresponding tokens from your database. Build that logic into your own sender and make it observable, because stale tokens silently degrade delivery rates over time.
- Is this package actively maintained and safe for production?
- The adoption signal is effectively zero, with no stars, no dependents, and no indication of upstream activity. That means you own the fork from day one, including security patches and compatibility fixes with future Laravel and Symfony releases. For a delivery-critical path like push notifications, that maintenance burden is usually not worth accepting.
- How do I test or mock the FCM sender in my test suite?
- The bundle exposes PSR-compatible services, so you can inject and mock them in Symfony tests, but that does not carry over to Laravel. In a Laravel app, define your own PushSender interface at the boundary and bind a fake implementation in the container for tests. That keeps your test suite decoupled from whichever FCM client you eventually choose.
- How do I migrate an existing Symfony service off this bundle when porting to Laravel?
- Do not greenfield on the bundle. If a Symfony service already uses it, define a PushSender interface at the boundary, wrap the bundle behind an adapter, and build a Laravel-native HTTP v1 implementation alongside it. Run both behind a feature flag, compare results in production, then delete the bundle and its transitive Symfony dependencies in a single follow-up change.
Weaver
How can I help you explore Laravel packages today?