Goridge Laravel Package

Product Decisions This Supports

• The real decision it informs is still "do we adopt RoadRunner?" — not "do we adopt Goridge?" This package is the wire protocol that lets RoadRunner's Go server dispatch work to PHP workers. Its maintenance health is a proxy signal for integration risk in the broader RoadRunner bet.
• Runtime architecture: FPM vs persistent workers. If you're evaluating RoadRunner, Laravel Octane (Swoole/FrankenPHP), or staying on php-fpm, a maintained, MIT-licensed Goridge implementation lowers the risk of the RoadRunner path and gives you a credible benchmark candidate.
• Build vs buy (clear "buy," or rather "don't build"). If you ever consider a custom Go↔PHP bridge, this package saves you from designing binary framing, payload typing, and error transport yourself. Building that in-house is a multi-week detour with no product differentiation.
• Codec lifecycle is now an explicit decision. 4.6.0 deprecates MsgpackCodec and Frame::CODEC_MSGPACK. If you rely on msgpack for compact binary payloads or typed transport, treat this as a scheduled migration: identify any direct codec selection, confirm the replacement codec with your pinned RoadRunner server version, and re-run throughput/latency benchmarks on the non-deprecated path. If you consume Goridge only transitively through the SDK and never select a codec explicitly, this is likely invisible — but it should still be checked before a RoadRunner commitment.
• Use-case gating. It only becomes relevant if you have polyglot topology (Go control plane, PHP workers) or a genuine high-throughput inter-process RPC need. It is invisible to end users and should never appear in a customer-facing roadmap conversation.
• Roadmap signal, not roadmap content. A recent release date suggests the underlying ecosystem is actively maintained — useful as one input to a 12–24 month platform commitment, not as a reason to commit on its own. 4.6.0 reinforces active stewardship: deprecation plus dependency consolidation is maintenance hygiene, not a new capability.
• Packaging consolidation continues. 4.5.0 renamed the package to roadrunner/goridge; 4.6.0 now requires roadrunner/roadrunner instead of spiral/roadrunner. That further removes legacy naming ambiguity. The product-relevant consequence remains low-cost but concrete: update composer.json, CI cache keys, SBOM/dependency-scanning allowlists, runbooks, and internal docs that reference older package names.

When to Consider This Package

Consider it when:

• You have already chosen RoadRunner and need to author a custom worker, a protocol-aware client, or internal tooling that speaks Goridge directly.
• You're writing a Go service that must dispatch to PHP workers and want the framing solved.
• You need to debug or instrument worker↔server traffic at the protocol layer.
• You need a supported codec path and have confirmed you are not depending on the now-deprecated msgpack codec.

Look elsewhere when:

• You're on php-fpm with no persistent-worker requirement — the operational surface isn't justified, and Octane on Swoole/FrankenPHP is a simpler first step.
• You need general-purpose RPC (gRPC, JSON-RPC), a job queue (Redis, database queue), or a message bus (RabbitMQ, Kafka). Goridge is none of these.
• Your team cannot own Go infrastructure or the ops burden of a long-running application server.
• You are tempted to depend on it directly. With 0 direct dependents and a modest star count, treat it as transitive plumbing pulled in by the RoadRunner SDK. Pin the SDK, not this.
• You have hard requirements around msgpack transport and cannot absorb a codec migration. Reassess RoadRunner's fit or budget the migration explicitly.

Adoption criteria I'd apply: RoadRunner benchmark shows a meaningful win over current runtime; observability and graceful-restart story is understood; team has an owner for the Go-side process; the SDK version you pin ships a Goridge version with a release within the last 12 months; and no direct dependency on MsgpackCodec / Frame::CODEC_MSGPACK remains.

New criteria as of 4.5.0–4.6.0: treat roadrunner/goridge as canonical, and treat roadrunner/roadrunner as the expected RoadRunner package dependency going forward. If your composer.json, CI cache keys, SBOM/dependency-scanning allowlists, or internal runbooks mention older package names, schedule a rename. Also schedule a codec audit: deprecation is a low-cost migration now and a confusing incident later.

How to Pitch It (Stakeholders)

Executives: No new spend — MIT licensed. This is a low-level component of an optional performance architecture, not a product capability. The decision worth funding is whether to move PHP onto a persistent worker server; this package simply confirms that the integration layer for one such option is open source, actively maintained, and consolidated under the official RoadRunner namespace. 4.6.0 adds a deprecation watch item around the msgpack codec, but does not change the size or shape of the RoadRunner bet. Low blast radius, low standalone strategic value.

Engineering: It's the contract between the Go server and PHP workers — message framing, payload typing, error transport. Use it directly only if you're hand-rolling a worker or building protocol-aware tooling; otherwise it arrives for free with the RoadRunner SDK. 4.6.0 deprecates MsgpackCodec and Frame::CODEC_MSGPACK — no immediate removal, but anything explicitly selecting msgpack should plan a move to the supported codec path and be re-benchmarked. It also requires roadrunner/roadrunner instead of spiral/roadrunner, continuing the 4.5.0 rename cleanup. Recommended posture: consume transitively via the SDK, never pin Goridge independently; if you must reference it, use the new package names and avoid deprecated codec constants.

Recommendation: Don't write an ADR for this package. Write one for RoadRunner — benchmark versus current runtime, operational ownership, observability, rollback plan — and let this package appear in that ADR as a dependency, not as a subject. Add one line to that ADR confirming the codec path and package names you will standardize on. Its value is entirely contingent on the larger bet; 4.5.0–4.6.0 strengthen the case slightly through first-party stewardship, but do not change the size or shape of the bet.