Roadrunner Tcp Laravel Package

Technical Evaluation

Architecture fit: Unchanged in substance and still well substantiated. The package remains the official roadrunner-php/tcp component, extending RoadRunner's worker model to raw TCP with persistent connections, custom/binary protocols, and low-latency internal RPC. The 4.3.1 patch reinforces the architectural story in one small but meaningful way: it aligns the transport with the canonical roadrunner/roadrunner core package rather than the legacy spiral/roadrunner name, which is the correct direction for a v3-era component and removes an earlier ambiguity about which core artifact this package actually targets.

Integration feasibility: Still high for RoadRunner v3 projects, conditional for v2. The 4.3.1 fix is a dependency-identity correction, not a feature: roadrunner/tcp now requires roadrunner/roadrunner instead of spiral/roadrunner. That is good hygiene on a greenfield install, but it changes the Composer resolution surface for existing consumers and is the single most important thing to validate in this release. Projects currently requiring spiral/roadrunner may now resolve two core packages, hit a conflict, or — worse — install both if the packages do not declare replace/provide against each other. Feasibility is therefore unchanged in principle but requires a lockfile-level check before upgrade.

Technical risk: Net roughly flat, with one risk retired and one sharpened. Retired: the core dependency is now unambiguous and points at the maintained package name. Sharpened: the prior semver-discipline concern is confirmed rather than resolved — 4.3.0 was a minor bump carrying a package rename and a runtime-major floor, and 4.3.1 is a patch bump that swaps a required dependency. Dependency swaps are BC-sensitive and this one shipped without an upgrade note or compatibility statement. Remaining from before and still unaddressed: no documented TLS story, thin real-world adoption, no documented disconnect/timeout/backpressure/binary-serialization semantics, and no benchmark data. New residual risk: dual-installation of spiral/roadrunner and roadrunner/roadrunner in the same application, with potential duplicate/aliased namespaces, double-registered service providers, or divergent worker bootstraps. Also worth noting: 4.3.0 → 4.3.1 landed in nine days, which is good responsiveness but also evidence of churn in the dependency layer.

Key questions:

• Does roadrunner/roadrunner declare replace/provide for spiral/roadrunner (or vice versa), and can both coexist safely? If not, what is the required removal sequence?
• Is the dependency swap in 4.3.1 a hard requirement (i.e., does 4.3.1 break projects still on spiral/roadrunner), and should it have been a minor/major bump rather than a patch?
• Is the earlier rename question now fully answered — namespace changes, config keys, .rr.yaml schema — or is there still only an alias?
• What is the supported upgrade path for RR v2 consumers — pin 4.2.x, and for how long will 4.2.x receive fixes?
• Does the package support or document TLS (now or roadmap)? If not, is terminating TLS at a sidecar/proxy the sanctioned pattern?
• Where are the error-handling semantics documented (disconnect, partial frame, timeout, worker recycle)?
• Are there benchmarks or reference workloads for TCP vs. HTTP under RoadRunner v3?
• Is release cadence automated, and who owns triage and dependency-update review?

Integration Approach

Stack fit: Unchanged in shape, now gated on both runtime version and core package identity. Ideal for internal service-to-service RPC, non-HTTP microservices, and socket-style tooling on RoadRunner v3. Still treat as greenfield or isolated-service only — absent TLS guidance it does not belong on a public-facing or cross-trust-boundary path unless encryption is terminated externally.

Migration path: Now three sequenced migrations rather than two. (a) Package identity: replace the previous Composer requirement with roadrunner/tcp, update imports/namespaces and published config references, re-run the suite. (b) Runtime: upgrade RoadRunner to v3 (.rr.yaml schema, worker bootstrap, core version constraints). (c) Core dependency reconciliation — new in 4.3.1: audit for spiral/roadrunner in composer.json and the lockfile, determine whether roadrunner/roadrunner supersedes it in your tree, remove the old requirement where possible, and diff the lockfile to confirm exactly one core package is installed. If your application or a third-party package hard-requires spiral/roadrunner, pin roadrunner/tcp to 4.3.0 until that is resolved and record it as technical debt with an owner and expiry date. Consumers unable to reach v3 at all should pin 4.2.x on the same terms.

Compatibility: Requires RoadRunner v3 and now roadrunner/roadrunner as the core dependency. Verify PHP constraints directly from composer.json rather than inferring from release notes, which remain silent on them. Check third-party packages that type-hint the old namespace or depend on spiral/roadrunner, and check any Spiral framework version in use — the core rename may cascade into framework-level constraints. Confirm no duplicate core packages and no autoload collisions after install.

Sequencing: 1) Confirm RoadRunner v3 feasibility (or decide to pin 4.2.x); 2) audit current spiral/roadrunner usage and decide the removal path; 3) composer require roadrunner/tcp in a branch and inspect the lockfile diff for dual-installation; 4) resolve namespace/rename fallout and re-run the full suite; 5) update .rr.yaml for the v3 TCP server schema; 6) stand up a minimal echo-style TCP service with a test client to prove the worker lifecycle; 7) add failure-path tests (disconnect, partial frame, malformed payload); 8) migrate one non-critical internal service; 9) observe stability and resource behavior before broader rollout.

Operational Impact

Maintenance: Still de-risked overall. Public repo, commit-level traceability, issue tracker, and a fixed changelog format indicate active stewardship, and the nine-day turnaround on 4.3.1 demonstrates someone is watching dependency health. The residual burden remains "track a young package's breaking changes," and 4.3.1 sharpens that: dependency swaps shipped as patch releases mean routine composer update runs can change your core package without a version signal. Require lockfile review on every bump, and treat patch releases as review-worthy rather than auto-merge.

Support: Improved marginally. Public issue tracker and commit history remain the primary assets, and the move to the canonical core package name gives a cleaner escalation story within the RoadRunner org. The community is still small — expect thin issue response times and few third-party references, so internal documentation of your integration stays the main support asset. Add a short internal note on the core-package rename so future maintainers are not surprised by the spiral/roadrunner history.

Scaling: Unchanged. Worker-based scaling inherits RoadRunner's strengths; TCP-specific tuning (connection caps, buffer sizes, per-worker concurrency, idle timeouts) remains your responsibility, and the package still publishes no numbers. Benchmark against your own load profile — and re-benchmark after the 4.3.1 upgrade rather than assuming core-package equivalence, since a different core artifact can carry different defaults.

Failure modes: Still the weakest area, and this release adds one. Undocumented disconnect/retry semantics remain: a dropped connection can hang clients or recycle workers unexpectedly, and framing/serialization errors can surface as silent corruption. New this release: dependency-resolution failures and dual-core installs. Symptoms range from a hard Composer conflict (good — loud) to two core packages coexisting with aliased namespaces or duplicate service providers (bad — silent, and potentially manifesting as inconsistent worker behaviour only under load). Also verify the rename does not silently break autoloading or cached config in already-built images. Keep the split-version-fleet failure mode from the previous review: enforce a single supported package/runtime matrix in CI.

Ramp-up: Essentially unchanged. The public repository makes developer onboarding easier than the earlier black-box state, but manual protocol handling (framing, encoding, connection lifecycle) is a socket-programming skill, not a Laravel-idiomatic one. Budget 1–2 weeks for a v3 spike, roughly half a week for the rename plus core-dependency reconciliation, and keep the 2–4 week estimate for a first production service. Add explicit onboarding material covering the core-package history and TLS termination via proxy, since the package still does not solve encryption.