Jsonrpc Bundle Laravel Package

Product Decisions This Supports

• Framework-fit decision (critical): This is a Symfony bundle, not a Laravel package. If the codebase is Laravel, this is a disqualifier, not a trade-off. If the stack is Symfony, it becomes relevant. Confirm framework before any further evaluation.
• Build vs. buy for internal RPC APIs: If we need to expose existing service-container services to internal clients (admin consoles, worker processes, first-party SPAs, partner integrations), this package removes the "write a controller per method" tax. That is a genuine build-cost reduction versus hand-rolling JSON-RPC dispatch, auth hooks, and error envelopes.
• Protocol choice on the roadmap: Informs whether an upcoming API ships as JSON-RPC 2.0 versus REST/GraphQL. JSON-RPC is a strong fit when the API is function-shaped (named operations, batch calls, notifications) rather than resource-shaped — e.g., internal orchestration endpoints, calculation/validation services, tooling backends.
• Migration off SOAP/legacy RPC: Useful lever if we are modernizing an existing XML-RPC/SOAP surface and want to preserve the "call a named method with typed params" contract while dropping the legacy stack.
• Vendor-risk posture for a low-traffic internal tool: With 30 stars and 0 dependents, this is a bus-factor-1 dependency. The decision it supports is really "acceptable only for non-critical, internally consumed surfaces where we can fork or replace in days."
• Not supported: Public/consumer-facing API strategy, developer-portal ecosystems, or anything needing OpenAPI-first documentation — JSON-RPC here has no schema/contract story out of the box.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony (Symfony 6/7-era, given a 2025-07 release) and services already live in the DI container with clean interfaces.
• The API is internal or trusted-partner, not public internet.
• The client contract genuinely benefits from JSON-RPC semantics — named methods, batching, notifications — rather than CRUD resources.
• We want minimum boilerplate: tag a service, expose its public methods, done.
• We accept a small, single-maintainer, MIT-licensed dependency and are willing to pin versions, read the source, and carry a fork if needed.
• Authentication/rate limiting/observability will be supplied by our own middleware and platform layers, not the package.

Look elsewhere when:

• The stack is Laravel — use a Laravel-native JSON-RPC package or plain controllers; do not bridge a Symfony bundle.
• You need OpenAPI/Swagger, SDK generation, or public developer documentation — choose REST (API Platform) or GraphQL.
• You need batteries-included auth, throttling, versioning, or a contract/schema registry; this is a thin transport layer.
• The surface is revenue-critical or customer-facing; a 30-star package with zero dependents is an unacceptable single point of failure there.
• Your team has no appetite for reading vendor source — with this dependency profile, you will eventually have to.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) Symfony component that lets us expose existing backend services as an internal API with very little new code — saving roughly the controller-and-plumbing work of a bespoke RPC layer. The trade-off is supplier risk: it is maintained by a single author with a small community and no downstream dependents. My recommendation is to treat it as an internal-tools accelerator, not a platform foundation — adopt only where a failure is containable and a fork is cheap. It changes no customer-facing roadmap commitments.

To engineering: It maps Symfony's service container directly onto JSON-RPC 2.0 — tag services, get a webservice. That means near-zero boilerplate, native reuse of our existing service layer, and no duplicate DTO/controller surface. Costs to plan for: it is Symfony-only (irrelevant to our Laravel work), it is not a security or documentation layer, and we should pin the version, vendor-review the dispatch path, and budget a half-day to prove we can fork and patch it. If we want schema contracts, auth policy, or public docs, those are ours to build — at which point compare against API Platform before committing.