Json Rpc Container Bundle Laravel Package

Technical Evaluation

Architecture fit. The package name (json-rpc-container-bundle) follows Symfony Bundle conventions (*Bundle namespace, DI container compilation passes, Resources/config service definitions), not Laravel package conventions (*ServiceProvider, *Facade, publishable config/migrations, composer.json extra.laravel.providers auto-discovery). That is the single most important architectural signal here: this is likely a Symfony-oriented JSON-RPC server implementation wrapped around PSR-7/PSR-15 middleware and a container-aware RPC dispatcher. In a Laravel application it can only be adopted as a standalone library that we wire into the framework ourselves, not as a first-class Laravel package.

Integration feasibility. Feasible but non-trivial. A JSON-RPC layer needs three things from the host framework: (1) a routing entry point accepting POST /rpc (or whatever path we choose), (2) a method-to-handler mapping that resolves through our existing service container, and (3) HTTP request/response translation into PSR-7 if the package expects PSR interfaces. Laravel can satisfy all three — route in routes/api.php, handler resolution via app()->make(...), and HTTP bridging via psr/http-message plus framework response re-shaping. The open question is whether 2.0.0 requires a Symfony ContainerInterface/CompilerPass at boot, because that would force either a container adapter or an independent league/container instance for the RPC subtree.

Technical risk. Moderate-to-high, for a specific and fixable reason: we have no information about what changed. The release notes for 2.0.0 consist solely of a 1.0.0...2.0.0 compare link. A major version bump is a contract, and by semver it permits arbitrary breaking changes. Adopting 2.0.0 without reading the diff means absorbing whatever those breaks are at integration time. Secondary risks: the 1.0.0 → 2.0.0 gap suggests a young, fast-moving codebase with a single or small maintainer set; JSON-RPC dispatch is a security-sensitive surface (method enumeration, unserializing parameter payloads, error-detail leakage); and the Laravel/Symfony impedance mismatch adds adapter code we will own indefinitely.

Key questions.

1. What precisely changed between 1.0.0 and 2.0.0 — was the major bump a namespace/API reshape, a PSR version bump, a minimum PHP raise, or a dependency removal? The compare link is the only evidence and must be read before any decision.
2. Does the package depend on symfony/dependency-injection and symfony/http-kernel at runtime (hard coupling) or only suggest/dev? If hard, it pulls the Symfony kernel into a Laravel app — heavy and philosophically awkward.
3. Are handlers resolved by container ID, by class-string, or by explicit registration array? Only the third is a clean Laravel integration.
4. Is there a documented compatibility matrix (PHP, PSR-7 implementation, Laravel version)? None is in evidence.
5. What is the authentication/authorization story for exposed RPC methods? For a JSON-RPC endpoint this is the difference between a feature and an incident.

Integration Approach

Stack fit. Treat this as a library, not a bundle. We will not install symfony/framework-bundle to satisfy it. Install the package, add a thin Laravel adapter (~150–250 LOC) that registers a dedicated route, maps RPC method names to container bindings under a namespaced prefix (rpc.<domain>.<action>), and converts the package's response object into an Illuminate\Http\JsonResponse. If the package requires Symfony services we cannot satisfy, construct a scoped container for the RPC surface only, so the blast radius is one module rather than the app.

Migration path. Greenfield integration is the only sensible path — we have no prior assessment, so this is a net-new adoption decision rather than an upgrade. Do not begin on 2.0.0. Pin 1.0.0 first, build the adapter and a small conformance test suite against it (happy path, unknown method, invalid params, oversized payload, batch request if supported), then attempt the 2.0.0 bump and let that suite enumerate the breaking changes empirically. This converts an undocumented major bump into a measurable diff and gives us a rollback point.

Compatibility. Assume PHP 8.x. Verify the PSR-7 implementation in use matches whatever the package expects (nyholm/psr7 and guzzlehttp/psr7 differ in subtle ways) and that Laravel's HTTP layer is not double-consuming the request body. Confirm whether the package's error responses honor the JSON-RPC 2.0 spec's code/message/data shape, since clients will depend on it.

Sequencing.

1. Read the actual 1.0.0...2.0.0 diff (blocking; everything else is speculative until done).
2. Spike: install 1.0.0, stand up one method end-to-end behind auth middleware, in a branch.
3. Write the conformance suite; attempt 2.0.0 upgrade against it.
4. Decision gate: if the 2.0.0 diff shows container reshaping we cannot cleanly adapt, stop and evaluate alternatives.
5. Only then productize: config publishing, method registry conventions, docs.

Operational Impact

Maintenance. The adapter is ours; the package is theirs. Every upstream release requires us to re-run the conformance suite, and the absence of a maintainable changelog means we will be doing diff archaeology each time. Budget a recurring line item, not a one-off. A single-maintainer dependency on a security-sensitive RPC surface should be recorded explicitly on the dependency risk register.

Support. Upstream support is community/GitHub-issue best-effort — no vendor SLA, no disclosed maintainer roster or release cadence. Internal support burden lands on the adopting team, who will be the only people on staff who understand both the package and our adapter. That is a bus-factor of one until a second engineer does the integration.

Scaling. JSON-RPC dispatch is stateless and horizontally trivially, so scaling the endpoint is a matter of our existing web tier — no new infrastructure. The real scaling concerns are payload size limits (set them explicitly; default body limits are a DoS vector), per-method rate limiting, and whether method resolution performs container lookups per call in a hot path. Batch requests, if supported, amplify all three and need a cap.

Failure modes.

• Silent API drift: upstream 2.x patch/minor makes a behavioral change our suite doesn't cover → malformed responses reach clients.
• Container coupling failure: framework upgrade changes service resolution semantics → RPC handlers fail to instantiate, endpoint 500s entirely rather than degrading per-method.
• Error leakage: uncaught exceptions serialized into JSON-RPC error.data expose stack traces or internal state. Mandate a sanitizing error handler in front of the dispatcher.
• Auth bypass: RPC method dispatch that bypasses Laravel middleware — very easy to do accidentally since the package routes internally. Verify auth middleware wraps the route, not the handler.
• Body-consumption conflict: package reads php://input after Laravel has already parsed it → empty params, confusing 400s.

Ramp-up. Low ceiling, moderate floor. An engineer familiar with JSON-RPC 2.0 and Laravel's container can complete the spike in roughly 3–5 days; the adapter and test suite add 1–2 weeks. The ongoing cost is the diff-review ritual at each upstream release, which is cheap if the conformance suite is good and expensive if it is not. Bottom line: conditionally viable as an internal library integration; not viable as a drop-in Laravel package, and not approvable until the 2.0.0 changelog gap is closed.