Json Rpc Laravel Laravel Package

Product Decisions This Supports

• Unified RPC surface for web and mobile clients. RpcRouter::on() now accepts Laravel-style controller actions ([SomeController::class, 'method']), so existing HTTP controllers can be re-exposed as RPC methods without duplicating logic. This lowers the cost of shipping a single backend API that serves a SPA, a mobile app, and internal tooling, and it makes RPC endpoints a realistic option for teams already organized around Laravel controllers.
• Build vs. buy for internal/partner APIs. The package now covers routing, dispatch, and Laravel lifecycle integration for RPC-style endpoints, which removes a credible chunk of custom glue code from the build column. For internal service-to-service or BFF-style traffic, this shifts the calculus toward adopting a package rather than maintaining bespoke RPC plumbing.
• Roadmap sequencing and platform support matrix. The release moves the floor to Laravel 11 and the ceiling to Laravel 13, plus PHP 8.5. This is the data point that lets you schedule framework upgrade work with confidence: the package tracks the Laravel release train, so adopting it does not pin your platform. Conversely, any product line still on Laravel 10 or earlier cannot adopt v2.8.0 and must either stay on an older package version or schedule the framework upgrade first.
• Consolidating controller logic as the canonical API layer. Because controller actions are now first-class RPC targets, the decision "where does business logic live?" resolves toward controllers/services rather than a parallel RPC layer. That is a simplification worth reflecting in architecture standards.
• Forward-looking bets. Laravel 13 and PHP 8.5 support signal the maintainer is tracking upstream before those versions are broadly deployed. That is a positive signal for a package you might depend on across a multi-year roadmap.

When to Consider This Package

Consider it when:

• The application is on Laravel 11 or newer — this is now a hard floor in v2.8.0 and the single most important gating criterion.
• You want an RPC-shaped API (single endpoint, method-name dispatch, batched or typed calls) rather than resource-oriented REST, and you want it to live inside your existing Laravel app with familiar middleware, auth, and validation.
• You already have controller actions that represent the behavior you want to expose; the new [Controller::class, 'method'] syntax lets you wire them up directly instead of writing adapter classes.
• Your consumers are first-party — your own SPA, mobile app, internal dashboards, or trusted partners — where you control the client and do not need a publicly documented, OpenAPI-first contract.
• You want low operational overhead: no separate service to deploy, no schema compiler, no new infrastructure.

Look elsewhere when:

• You are on Laravel 10 or older and cannot upgrade — v2.8.0 will not install, and staying on an older major means forgoing the controller-action support.
• You need a public, contract-first API with generated OpenAPI/Swagger docs, versioning guarantees, and broad client codegen. REST or GraphQL tooling serves that better.
• Your requirements are GraphQL (client-selected fields, single schema) or gRPC/high-throughput binary transport — this package is not a substitute for either.
• You need fine-grained per-method HTTP semantics (distinct cache headers, status codes, CDN behavior per resource). A single RPC endpoint collapses those distinctions.
• You require strict semantic versioning guarantees or long-term support commitments; verify the maintainer's release cadence and backward-compatibility policy before treating it as a platform dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk dependency that lets our Laravel backend expose RPC-style endpoints to our own web and mobile clients without building and maintaining custom routing and dispatch code. The v2.8.0 release is a maintenance release with one meaningful capability gain — we can now point RPC methods directly at our existing controllers — and a clear platform story: it supports Laravel 11 through 13 and PHP 8.5. The practical implication is that adopting it does not constrain our framework upgrade path, and it reduces the amount of bespoke API plumbing we own. The one decision it forces is timing: our Laravel version must be 11 or higher.

For engineering: v2.8.0 adds controller-action targets to RpcRouter::on(), so [SomeController::class, 'method'] replaces hand-written closures or adapter classes — less boilerplate, and existing tested controller logic becomes directly reachable over RPC. The release also raises the minimum Laravel to 11.0 and adds Laravel 13 and PHP 8.5 support, with dev dependencies (PHPStan 2.1.22, PHPUnit 10.5/11/12) and CI images (PHP 8.5, Xdebug 3.5.3) brought current. Action item: confirm our minimum Laravel version is 11.0+ before adopting; if we are below that, this upgrade is blocked on the framework upgrade and should be sequenced accordingly. There are no deprecations or removals listed, so the migration from the prior 2.x line is expected to be routine, but pin the version and run the suite against our supported Laravel matrix.