Weave Code
Stomp Laravel Package
centraldesktop/stomp
A PHP client for the STOMP messaging protocol, enabling applications to connect to brokers, subscribe to destinations, send messages, and handle acknowledgements. Useful for integrating PHP apps with STOMP-compatible queues and messaging systems.
centraldesktop/stomp is a PHP client for the STOMP messaging protocol, providing a straightforward way for applications to communicate with STOMP-compatible message brokers. It supports common messaging patterns such as publish/subscribe and point-to-point delivery, making it useful for integrating PHP services with asynchronous messaging infrastructure.
- Connect to STOMP-compatible brokers
- Publish messages to queues and topics
- Subscribe to destinations and consume messages
- Work with STOMP frames and headers
- Simple Composer-based integration for PHP projects
Frequently asked questions about Stomp
- Is centraldesktop/stomp a Laravel queue driver?
- No. centraldesktop/stomp is a standalone PHP STOMP 1.2 client and does not ship a Laravel queue connector, service provider, or facade. You can wire it into Laravel manually, but a real queue driver would require a custom connector around Laravel's queue abstraction. Treat it as a broker-specific transport rather than a drop-in Laravel queue replacement.
- How do I install centraldesktop/stomp in a Laravel project?
- Install it with Composer and then create a thin service provider or facade to manage connection configuration and lifecycle. There is no official Laravel installation guide, so you will need to define broker host, port, credentials, and STOMP options yourself. Validate the package against your PHP runtime early because its last release was in 2015. Expect to fork or patch it for modern PHP and Laravel compatibility.
- Which Laravel and PHP versions does centraldesktop/stomp support?
- There is no documented Laravel version support, and the package predates current Laravel releases. Its last release was 2015-02-12, so assume compatibility work is required for PHP 8+ and modern strict typing. Run a time-boxed spike on your target PHP and Laravel versions before committing. A fork may be necessary for autoloading, dependency constraints, and error handling fixes.
- Can I use centraldesktop/stomp with ActiveMQ or RabbitMQ?
- It is a STOMP 1.2 client, so it can work with STOMP-compatible brokers such as ActiveMQ or RabbitMQ with the STOMP plugin enabled. However, broker-specific framing, virtual hosts, receipts, transactions, and acknowledgement behavior must be verified independently. Test TLS, authentication, heartbeats, and reconnect scenarios against the actual broker. The client is only one part of the reliability equation.
- How do I publish and consume STOMP messages in Laravel with this package?
- Use the package's client API directly from a small internal service, then wrap it behind your own MessageClient interface so domain code does not depend on the package. For publishing, keep connections short-lived or carefully managed; for consuming, plan acknowledgement, retry, and dead-letter behavior explicitly. A custom Laravel queue connector is possible but should come after direct publish and consume use cases work. Start with a containerized spike and integration tests.
- Is centraldesktop/stomp maintained and safe for production?
- The project shows high technical and operational risk: last release in 2015, 5 stars, 0 dependents, and no active maintainer signal. There is no evidence of security patching, modern TLS/auth verification, heartbeat handling, or reconnect logic testing. Production use requires independent review, a fork or vendor strategy, and explicit ownership for maintenance. For most Laravel applications, it is not a safe default choice.
- How do I handle TLS, authentication, heartbeats, and reconnects with centraldesktop/stomp?
- These behaviors are not documented as production-ready, so treat them as integration work you must verify yourself. Test TLS certificate validation, credential expiry, virtual host selection, heartbeat intervals, and reconnect after connection drops against your broker. Add retry, idempotency, and dead-letter handling in your application layer because the client alone will not guarantee delivery. Avoid assuming it behaves like a mature Laravel queue worker.
- How should I test a centraldesktop/stomp integration in Laravel?
- Run a time-boxed spike in a container against the real broker, covering publish, consume, acknowledgement, negative acknowledgement, heartbeat, reconnect, TLS, and authentication. Add integration tests for duplicate delivery, partial acknowledgement, and message loss on reconnect. Keep the client behind an internal interface so you can fake it in unit tests and replace it later. Validate against your exact Laravel and PHP versions before sequencing application work.
- What are alternatives to centraldesktop/stomp for STOMP in Laravel?
- If STOMP is mandatory, prefer a maintained STOMP client or the broker's native protocol where possible. If STOMP is not mandated, use Laravel's supported queue drivers such as Redis, SQS, database, or Beanstalkd. For RabbitMQ, consider its native AMQP client or a maintained Laravel package instead of a 2015 STOMP fork. Evaluate alternatives behind the same internal MessageClient interface so migration is cheap.
- How do I isolate or replace centraldesktop/stomp later?
- Wrap the package behind an internal MessageClient interface and avoid leaking its API into domain code. Start with direct publish and consume use cases before building a Laravel queue connector, and put the integration behind a feature flag with rollback to the broker-native or existing transport. Document ownership, dependency review, and upgrade steps because the package has no active maintainer. This isolation lets you fork, replace, or remove it without rewriting business logic.
Weaver
How can I help you explore Laravel packages today?