Weave Code
Roadrunner Bridge Laravel Package
spiral/roadrunner-bridge
Integrates RoadRunner with the Spiral Framework, adding bootloaders for HTTP, queues, KV cache, gRPC, Centrifugo, TCP, metrics, logging, locks, and scaffolding. Requires PHP 8.1+ and Spiral Framework 3.14+.
RoadRunner integration package
Frequently asked questions about Roadrunner Bridge
- What does spiral/roadrunner-bridge actually do?
- It connects the RoadRunner application server to the Spiral Framework by providing bootloaders that wire RoadRunner plugins into the framework container and lifecycle. You register the desired bootloaders at the top of your LOAD list to enable HTTP, Queue, Cache/KV, gRPC, Centrifugo, TCP, Metrics, Logger, Lock, and Scaffolder integrations. It does not replace the RoadRunner binary or your RoadRunner YAML configuration.
- How do I install spiral/roadrunner-bridge?
- Install it with composer require spiral/roadrunner-bridge, then add the relevant Spiral\RoadRunnerBridge\Bootloader classes to the top of your LOAD constant. The package requires PHP 8.1+, Spiral Framework 3.14+, and the protobuf extension is recommended. You still need a RoadRunner binary and the matching plugin configuration in your RoadRunner YAML file.
- Does spiral/roadrunner-bridge work with Laravel?
- This package targets the Spiral Framework, not Laravel directly; its bootloaders integrate with Spiral's container and lifecycle. Laravel developers evaluating persistent-worker setups should confirm whether they need a Laravel-specific RoadRunner integration instead. The provided context does not confirm official Laravel version support for this bridge.
- What PHP and Spiral Framework versions are required?
- The documented requirements are PHP 8.1 or newer and Spiral Framework 3.14 or newer, with the protobuf extension recommended. Check the Composer constraints for the exact release you install, especially when moving to v4.0.0.
- Which bootloaders are available and are they all required?
- The package provides HTTP, Queue, Cache/KV, gRPC, Centrifugo, TCP, Metrics, Logger, Lock, and Scaffolder bootloaders. They are optional and should be registered only when your application uses the corresponding RoadRunner plugin. Registering them at the top of the LOAD list ensures the integration is available before your application bootloaders run.
- What changed in v4.0.0 that could break my application?
- v4.0.0 marks previously usable implementations as internal, removes deprecated APIs, reworks logger handling, normalizes TCP and Centrifugo interceptor arguments, and fixes EXIT command handling. Internal classes are no longer protected by SemVer, so extending, decorating, or type-hinting them can break in future minor releases. The provided context does not include a documented 3.6 to 4.0 BC-break list or upgrade guide, so verify the changelog before upgrading.
- Why did my logging configuration stop working after upgrading?
- The v4.0.0 logger changes rework the PSR-3 and RoadRunner log handler, including Alert and Emergency level mapping, bubble and log-level semantics, normalized output, and removal of slash and Unicode escaping. Existing logging.php or RoadRunner YAML handler configurations should be treated as non-portable until verified. Log-based alerting, dashboards, and parsers may also need retuning if emitted line formats changed.
- Are internal classes safe to extend or type-hint?
- No. v4.0.0 explicitly makes implementations internal, meaning SemVer no longer protects them. Any code that extends, decorates, or type-hints those classes is on an unsupported path and may break in minor releases. Prefer public interfaces and bootloader configuration over depending on internal implementation classes.
- How does the bridge handle persistent worker state and database connection resets?
- RoadRunner uses long-lived PHP workers, so static caches, reused connections, and request-scoped state are the dominant design concerns. The provided context does not answer how the bridge handles database connection resets between requests. Verify this behavior in your Spiral and RoadRunner setup and test it under realistic load before production.
- Is spiral/roadrunner-bridge production-ready and how should I test it?
- The v4.0.0 changes harden observability and graceful shutdown, and the release shows active maintenance across multiple contributors. Before production, test with the actual RoadRunner binary and YAML configuration, including worker exit paths, log output, interceptor arguments, and queue or console command behavior. Confirm that internal-class usage and any removed deprecated APIs are eliminated from your codebase.
Weaver
How can I help you explore Laravel packages today?