Weave Code
Gps Messenger Bundle Laravel Package
petitpress/gps-messenger-bundle
Google Pub/Sub transport for Symfony Messenger with zero extra dependencies beyond core Symfony and Pub/Sub libraries. Supports DSN and options config, automatic topic/subscription creation, message ordering via OrderingKeyStamp, dead letter policies, and keep-alive for long-running workers.
The bundle provides a simple implementation of Google Pub/Sub transport for Symfony Messenger.
Frequently asked questions about Gps Messenger Bundle
- Is petitpress/gps-messenger-bundle a Laravel queue driver?
- No. It is a Symfony bundle that registers a gps:// transport for Symfony Messenger backed by Google Cloud Pub/Sub. It does not plug into Laravel's config/queue.php driver abstraction for redis, sqs, database, or beanstalkd. Using it in a Laravel app means running Symfony Messenger alongside Laravel's queue system, or isolating it as a dedicated consumer service.
- How do I install and register the GPS Messenger bundle?
- Install it with composer require petitpress/gps-messenger-bundle --no-scripts. It requires symfony/messenger, google/cloud-pubsub, and symfony/options-resolver. In Symfony you register the bundle in config/bundles.php and configure the gps:// transport in messenger.yaml. In Laravel there is no bundle registration, so you need a Symfony kernel bridge or a separate Symfony consumer service.
- Which Laravel and Symfony versions are supported?
- The package is Symfony-first, not an official Laravel package. Its support matrix shows 3.x for Symfony >=5.4 and <8.0, and 4.x for Symfony >=7.4. Laravel 10 and 11 pin their own Symfony component versions, so Composer dependency resolution is the first real gate. Validate compatibility with an isolated proof of concept before committing.
- How do I configure the Pub/Sub DSN, options, and credentials?
- Configure a gps:// transport DSN in Symfony Messenger with options for project, topic, subscription, deadLetterPolicy, enableMessageOrdering, and ackDeadlineSeconds. Configuration lives in Symfony YAML such as messenger.yaml, not Laravel config/*.php files. Credentials come from GOOGLE_APPLICATION_CREDENTIALS and GCLOUD_PROJECT or application default credentials, ideally through a secrets manager rather than committed JSON.
- Does the bundle create Pub/Sub topics and subscriptions automatically?
- Yes, it supports automatic topic and subscription creation and lets you disable that behavior. This is convenient for development and emulator-based testing. In production, many teams prefer infrastructure-as-code for topics, subscriptions, IAM, and dead-letter policies. If you keep auto-creation enabled, audit permissions and naming carefully.
- How does message ordering work, and does it support long-running workers?
- Message ordering is supported through the OrderingKeyStamp and the enableMessageOrdering option. The actual ordering semantics are largely delegated to Pub/Sub subscription configuration, so test ordering keys end to end with your publishers and consumers. The bundle also includes keep-alive support for long-running Symfony Messenger workers. Confirm worker timeouts and deployment supervision in your runtime.
- How are dead letters, retries, and exactly-once delivery handled?
- The bundle supports deadLetterPolicy through DSN or options configuration. Retry behavior, backoff, maximum delivery attempts, and dead-letter routing depend heavily on the Pub/Sub subscription configuration rather than the bundle alone. Do not assume exactly-once semantics without validating them. Test DLQ IAM permissions, monitoring, and replay procedures in a staging project.
- Can I test it locally without a real Google Cloud project?
- Yes, you can use the Google Pub/Sub emulator by setting PUBSUB_EMULATOR_HOST and development credentials. The Google SDK reads some values through getenv, so configure Symfony Dotenv with usePutenv where needed. Test with explicit DTO or envelope contracts because Laravel Eloquent models are not serializable by default. Also verify message size limits and serialization compatibility with downstream services.
- What production risks should a Laravel team evaluate?
- The dominant risk is framework mismatch: dual DI containers, two messaging paradigms, and unclear operational ownership. Adoption is low, with roughly 30 stars, zero dependents, and a single maintainer, so a fork or direct google/cloud-pubsub fallback may be necessary. GCP lock-in is real, and Pub/Sub's 10 MB message cap means large Laravel payloads should be offloaded to Google Cloud Storage with a reference in the message.
- What alternatives should I consider before adopting this bundle?
- Weigh Laravel's native SQS, Redis, or database queue drivers first if they meet the requirement. A thin custom Laravel queue driver wrapping the Pub/Sub SDK, or Laravel publishing directly via google/cloud-pubsub with this bundle running in a Symfony consumer sidecar, often bounds the blast radius. Choose Pub/Sub specifically when cross-service GCP events require it, not merely as a replacement for Laravel's queue system.
Weaver
How can I help you explore Laravel packages today?