Grpc Laravel Package

Product Decisions This Supports

• Build vs. buy for inter-service communication: If your roadmap includes exposing or consuming gRPC APIs from a PHP codebase, this package is the "buy" option for the PHP-side plumbing rather than hand-rolling protobuf serialization and HTTP/2 framing.
• Microservices / polyglot architecture decisions: Enables a PHP (Laravel/Symfony) service to participate as a first-class citizen in a gRPC mesh alongside Go, Java, Python, or Rust services — the decision to keep PHP in the stack vs. re-platforming a service to Go.
• Monolith-to-services migration: Justifies carving out internal APIs (e.g., auth, billing, search) as gRPC endpoints while the core product stays in PHP, without requiring a full rewrite.
• Performance-sensitive internal APIs: Where REST/JSON overhead (serialization cost, payload size, latency) is a measured bottleneck, gRPC via RoadRunner's persistent workers is a plausible optimization path.
• Streaming features: Server-streaming or bidirectional-streaming use cases (live feeds, telemetry ingestion, long-running jobs) that are awkward over traditional PHP request/response.
• RoadRunner adoption decision: This package only makes sense with RoadRunner; evaluating it is effectively evaluating RoadRunner as your PHP runtime — a larger platform bet.

When to Consider This Package

Consider it when:

• You already run (or have committed to) RoadRunner as your PHP application server. This SDK is the PHP-facing bridge for RoadRunner's gRPC plugin — it is not a standalone gRPC client.
• Your architecture is polyglot and contract-driven: you have .proto files, a schema registry or versioning discipline, and teams that understand protobuf.
• You need streaming or high-throughput internal RPC that REST/JSON cannot serve economically.
• You want typed, code-generated clients rather than hand-maintained HTTP clients.
• You can absorb maintenance risk in-house: pin versions, track RoadRunner releases, and be prepared to debug at the transport layer.

Look elsewhere when:

• You're not on RoadRunner. The standard ext-grpc PHP extension (or a Go/Node sidecar) is the conventional path; this package will not help you.
• Plain REST/JSON is sufficient. Most Laravel product work — CRUD APIs, webhooks, third-party integrations — does not need gRPC, and adding protobuf tooling is real, ongoing cognitive overhead.
• You require vendor-backed support or a large ecosystem. With ~66 stars and zero listed dependents, the community surface is thin: fewer Stack Overflow answers, fewer battle-tested production stories, and limited third-party tooling. Treat it as infrastructure you own, not a community you can lean on.
• You need browser-facing gRPC. Browsers don't speak raw gRPC; you'd need gRPC-Web or a gateway, which adds a component this package doesn't provide.
• Your team has no protobuf/HTTP-2 experience and no near-term reason to acquire it. The learning cost is a hidden line item.

Diligence checklist before adopting: confirm compatibility with your RoadRunner and PHP versions; check release cadence against your support window; review whether the gRPC plugin is bundled in your RoadRunner build; and run a timeboxed spike against one real service boundary before committing it to the architecture.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, MIT-licensed integration library that lets our PHP services speak gRPC — the high-performance RPC protocol used by most modern microservice platforms — through RoadRunner, the application server we would run PHP on. Strategically, it means we can keep our PHP investment and still interoperate with services written in Go, Java, or Python, instead of re-platforming parts of the product. The cost is low (no license fee) but so is the adoption: it's a niche package with a thin community, so I'd recommend a bounded pilot on one internal service boundary rather than a company-wide standard, with an explicit owner for upgrades and a fallback plan.

For engineering (summary): The RoadRunner gRPC SDK gives us generated protobuf clients and servers that run inside RoadRunner's persistent worker model — non-blocking, high-concurrency, and a better fit for our runtime than the blocking ext-grpc extension. It's a thin bridge, not a framework: it assumes RoadRunner is present, assumes .proto contracts are managed somewhere sensible, and assumes we're comfortable debugging at the HTTP/2 layer. The trade-off is maturity — small star count, no dependents, and a single-maintainer risk profile — so we should pin versions, vendor the dependency if practical, add a contract test suite around our first service, and treat RoadRunner compatibility as a tracked upgrade item each release cycle. Success criteria for the pilot: one real cross-service call path in production, measurable latency improvement or streaming capability we couldn't get otherwise, and no more than a defined maintenance budget per quarter.