- Is redjanym/fcm-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. It relies on Symfony's kernel, Bundle class registration, DI extension config trees, and services.yaml conventions to wire up its service. That means it cannot be dropped into a Laravel app the way a Composer package with a Laravel service provider can.
- Can I install redjanym/fcm-bundle in a Laravel application as-is?
- No. Laravel has no equivalent bundle loading mechanism, so the bundle's DI extension and configuration tree will never be bootstrapped. Composer may install the code, but nothing will register the service or read its config. The reusable part is the FCM HTTP v1 transport underneath the Symfony wrapper, not the wrapper itself.
- How do I send Firebase Cloud Messaging push notifications from Laravel using this bundle's transport?
- The recommended path is to adopt the transport client and discard the bundle. Depend on the underlying PHP FCM v1 client library the bundle wraps, then expose it through a Laravel service provider, a NotificationChannel, and a queued job. That glue is small and well bounded, typically one to two developer-days plus test coverage. A Symfony sidecar exposing an internal send endpoint is only worth it if another team already runs Symfony and wants to own push as a shared service.
- Does redjanym/fcm-bundle support the FCM HTTP v1 API with OAuth2 service-account authentication?
- Yes, the bundle targets FCM HTTP v1, which mandates a Google service-account JSON and OAuth2 access tokens rather than the legacy server-key model. That is a materially higher secret-management burden and the most likely source of production incidents. Before committing, check how access tokens are cached and refreshed, whether it is in-process, PSR-6 cache, or re-minted on every call.
- Can it send to topics and multicast device token batches with platform-specific overrides?
- The package description states you can target device tokens or topics and build notification plus data payloads for Android, iOS, and web clients. Confirm directly whether multicast or batch sends up to the 500-token per-request limit are supported, and whether APNs and Android-specific overrides are exposed. These details matter more than the payload builder for real-world delivery.
- Is redjanym/fcm-bundle production-ready and actively maintained?
- The ecosystem signals are weak: roughly 43 stars and zero dependents means essentially no production validation outside the author. It is a single-maintainer library with no commercial backing and no SLA. One metadata flag is a future-dated last release, so verify release frequency and maintenance activity directly against Packagist and GitHub tags before committing. The MIT license and Google-owned FCM v1 API contract lower the legal and API risk, so a fork-and-adopt arrangement is a realistic fallback if the wrapper is abandoned.
- Which PHP and Laravel versions does redjanym/fcm-bundle support?
- Because it is a Symfony bundle, its composer constraints describe Symfony and PHP support, not Laravel. PHP 8.2+ alongside Laravel 10 through 12 is likely fine for the transport code, but you must verify the actual constraint matrix yourself. Also check which Guzzle major and google/auth versions it pins, since transitive pins can lag PHP minor releases.
- How do I handle FCM error codes like UNREGISTERED and prune invalid device tokens?
- FCM returns per-token error codes such as UNREGISTERED and SENDER_ID_MISMATCH that should feed a token-pruning job. Check whether the library surfaces these codes in a structured, per-token way rather than collapsing them into a generic exception. If it does not, wrap the client so your Laravel job can catch the response and mark dead tokens in your database.
- How should I store the Google service-account JSON and cache access tokens in Laravel?
- Keep the service-account JSON in your secrets manager rather than plaintext in .env, and inject it into the client through a config entry. Access tokens should be cached so you are not re-minting OAuth2 credentials on every send. Add your own logging and metrics around the client, since observability in the bundle is thin and FCM failures are otherwise silent.
- How do I test FCM push notifications in Laravel without sending real messages?
- Bind a fake implementation of your push client into the container during tests and assert on the message payloads and target tokens it receives. Use Notification::fake() for the notification layer and Queue::fake() to confirm the job is dispatched and retried correctly. Keep one integration test against FCM behind an environment flag so you can verify credentials and message shape without slowing the suite.