Json Rpc Container Bundle Laravel Package

Product Decisions This Supports

• Transport/API style choice: whether to expose existing internal PHP services as method-oriented JSON-RPC calls instead of hand-rolling REST controllers or adopting GraphQL. The package's stated scope — wiring JSON-RPC endpoints through a container — is a "thin transport over services we already have" play, not a public API design tool.
• Build vs. buy on glue code: container auto-wiring for RPC handlers is code your team would otherwise write and maintain. The decision is whether a small third-party abstraction costs less than ~a few hundred lines of owned plumbing.
• Roadmap sequencing and coupling risk: 2.0.0 is a major bump published with no changelog beyond a diff link. Plan adoption behind an internal seam so handler code never imports the package's interfaces directly, keeping a future swap or version pin cheap.
• Risk-register entry: the 1.0.0 → 2.0.0 migration cost is currently unknown and must be budgeted as discovery work, not as a version-string change.

Evidence caveat: the only signals available are the package name and a version number. Everything above is a hypothesis to validate in a timeboxed spike — not a conclusion. No adoption data, benchmarks, or prior assessment exists.

When to Consider This Package

• You already have PHP services registered in a DI container and want to expose them as JSON-RPC methods without writing per-endpoint controllers.
• Your consumers are internal and trusted, where method-name coupling and non-cacheable POST semantics are acceptable.
• A spike-sized evaluation is affordable and the dependency is containerized behind your own abstraction.

Look elsewhere (or wait) when:

• You need a stable, documented contract. A major release with an empty changelog and no migration notes means unannounced breaking changes should be assumed. Do not upgrade 1.0.x blindly; review the compare diff first.
• You need public-facing APIs. JSON-RPC offers no resource-oriented caching, CDN/proxy friendliness, or OpenAPI/JSON Schema story out of the box.
• Laravel fit is unverified. The -bundle suffix implies Symfony conventions. Confirm service provider, config publishing, and container semantics before treating it as a first-class Laravel package.
• Ecosystem maturity is a requirement. There is no evidence of adoption, maintenance cadence, or issue responsiveness — a single 2.0.0 tag tells you nothing about either.

How to Pitch It (Stakeholders)

Executives: "A small open-source component that could let us expose internal PHP services over a typed RPC interface instead of hand-writing HTTP endpoints. It's cheap to trial but currently unproven — one major release with no published changelog. I'm recommending a short, timeboxed evaluation, not a commitment."

Engineering: "tourze/json-rpc-container-bundle went 1.0.0 → 2.0.0 with no changelog, only a compare link. Treat the major bump as unknown scope. Action: review the 1.0.0...2.0.0 diff, confirm Laravel compatibility (the 'bundle' naming suggests Symfony heritage), and report whether auto-wiring JSON-RPC handlers actually saves us code versus a thin custom controller. Timebox one spike; no production dependency until the diff is understood and the package is wrapped behind our own interface."