Roadrunner Grpc Laravel Package

Product Decisions This Supports

• Feature bets: Internal microservice APIs, service-to-service communication, and contract-first interfaces where REST/JSON latency or schema drift is a problem.
• Roadmap: A move toward service-oriented architecture, Laravel Octane/RoadRunner adoption, or polyglot backend communication using Protocol Buffers. The 3.8.x line explicitly targets RoadRunner v3, so this maps to a RoadRunner v3 upgrade track rather than the v2-era runtime.
• Build vs buy: Buys an MIT-licensed gRPC SDK for RoadRunner instead of building a PHP-to-gRPC worker bridge, protobuf bootstrapping, error mapping, TLS, and metrics plumbing in-house.
• Use cases: High-throughput internal APIs, streaming RPCs, typed cross-language contracts, and backend services where gRPC is already the platform standard.
• Architecture decision: This is not a generic Laravel package. It is a runtime commitment: adopt it when RoadRunner v3 is already or intentionally becoming the application server.
• Dependency hygiene decision (3.8.0, reinforced in 3.8.1): The package is published as roadrunner/grpc (renamed from roadrunner-php/grpc). Release 3.8.1 then swaps its own runtime dependency from spiral/roadrunner to roadrunner/roadrunner. Both are supply-chain and ownership decisions, not just version bumps — they touch composer.json, lockfiles, SBOMs, internal allowlists, private mirrors, and security scanning rules.
• Ecosystem consolidation signal: The two consecutive patch/minor releases point to the RoadRunner ecosystem finishing its own rename/ownership transition. That is a positive long-term maintenance signal, but it means internal tooling and docs may briefly lag behind the new names.

When to Consider This Package

• Consider it when: Laravel/PHP services already run on RoadRunner v3 (or are committed to that upgrade) and the team needs gRPC server support without leaving PHP.
• Strong fit when: The product needs strict protobuf contracts, cross-language clients, streaming RPCs, low-overhead internal communication, or Prometheus-visible service metrics.
• Operational fit when: The team can own .rr.yaml gRPC configuration, protoc stub generation, persistent PHP workers, TLS, middleware, and worker crash debugging.
• Look elsewhere when: The app runs on PHP-FPM/Apache/Nginx, needs browser-facing/public APIs, wants simple REST/JSON, lacks gRPC/Protobuf/RoadRunner operational experience, or is pinned to RoadRunner v2 with no near-term upgrade path.
• Migration watch (3.8.0 → 3.8.1): The rename to roadrunner/grpc and the RoadRunner v3 support line mean the previous package identity and runtime assumptions no longer match. 3.8.1 is a small bugfix, but it changes a composer requirement (roadrunner/roadrunner instead of spiral/roadrunner), so services that explicitly require spiral/roadrunner may hit a dependency conflict. Treat adoption as a planned migration: update composer.json requirements, republish/refresh private mirrors and allowlists, re-run composer update in a clean lockfile, re-verify autoloading and the separate gRPC entrypoint, and re-run worker lifecycle and error-mapping checks — not a routine patch bump.
• Adoption risk: Low public adoption signals and a small ecosystem mean it should be treated as strategic infrastructure with a pilot, not a default dependency. The renames can fragment documentation and community examples that still reference old package names, so expect to own more of the integration guidance internally. Maturity is helped by active RoadRunner ecosystem maintenance, PHP 8.4 fixes, RoadRunner v3 support, quick turnaround on packaging defects (3.8.1 landed nine days after 3.8.0), and MIT licensing.

How to Pitch It (Stakeholders)

• Executives: “This lets our Laravel/PHP services use the same high-performance gRPC contracts as the rest of our platform, reducing latency and infrastructure cost for internal APIs. It is now shipping under the roadrunner/grpc name and, as of 3.8.1, depends on roadrunner/roadrunner rather than the older spiral/roadrunner package — a cleaner long-term ownership story and one less custom RPC toolchain to maintain. It is MIT-licensed; the cost is a one-time dependency migration plus validation in one service before we standardize.”
• Engineering: “3.8.1 is a one-line dependency fix (roadrunner/roadrunner replaces spiral/roadrunner), but combined with the 3.8.0 rename to roadrunner/grpc and RoadRunner v3 targeting, plan the upgrade as a migration: update composer constraints, mirrors, SBOMs and allowlists; check for conflicts if anything still requires spiral/roadrunner; confirm the gRPC entrypoint and .rr.yaml config on v3; and re-test persistent-worker autoloading, TLS, middleware, streaming handlers and gRPC error metadata. Start with one bounded internal service, document the worker lifecycle, and only then roll it out to other services.”