Json Rpc Bundle Laravel Package

Technical Evaluation

What this actually is. neofusion/json-rpc-bundle is a Symfony bundle implementing a JSON-RPC 2.0 server, not a Laravel package. That distinction is the single most important fact in this assessment. The bundle's value is delivered through Symfony-specific machinery: bundle registration in the kernel, compiler passes, tagged services for method discovery, annotation-based method configuration, and integration with Symfony's HttpKernel/EventDispatcher request cycle. Strip that away and what remains is a modest set of handler and dispatcher classes.

Architecture fit. Poor for a Laravel codebase. Laravel has no concept of a bundle, no compiler passes, and no tagged-service method registration. Laravel's event dispatcher is contract-incompatible with Symfony's in the places this package relies on. Auto-configuration is precisely the feature that does not port, so "installing" it in Laravel is not a realistic path — you would be vendoring classes and re-wiring them by hand in a service provider, which is a fork, not an adoption. For a greenfield Laravel service, this package should be treated as a reference implementation to read, not a dependency to add.

Integration feasibility. Technically possible, economically unattractive. MIT license permits extraction of the handler logic. A competent Laravel engineer could reproduce equivalent behavior — method registration, named/positional parameter binding, error object mapping, batch loop, notification suppression — in roughly 200–400 lines. The JSON-RPC 2.0 spec surface is small and well-specified; there is no deep domain complexity here to justify taking on an unmaintained dependency.

Technical risk. High and asymmetric:

• Archived, last release 2019-05-28. No upstream fixes, no PHP 8.x compatibility work, no CVE response. Packages of this vintage commonly fail on PHP 8 due to implicit-nullable parameter deprecations, dynamic property creation, and return-type changes in JsonSerializable/ArrayAccess implementations.
• 0 dependents, 3 stars. No community validation, no production feedback, no peer knowledge base. Bugs you encounter are yours alone.
• Symfony 4-era dependency constraints likely conflict with a modern Laravel lockfile.
• The 0.94 opportunity score is worth reading correctly: it signals genuine ecosystem demand for a maintained JSON-RPC server, not that this package is good. The gap is real; this is not the vehicle that fills it.

Key questions to resolve before any code is written.

1. Do we actually need JSON-RPC 2.0 wire compliance, or do we need "an internal RPC-ish API"? If consumers are first-party, a REST or gRPC-style contract may be cheaper.
2. Who are the consumers — first-party SPA/mobile, or external third parties? External consumers make strict spec conformance and stable error codes non-negotiable.
3. Are batch requests and notifications required, or only single-call request/response?
4. What PHP and Laravel versions are mandated for the next 24 months?
5. Is there an existing RPC contract or client already in the field that must be preserved?
6. What is the auth/authorization model per method, and does it need per-method rate limiting?

Integration Approach

Stack fit. Assume a Laravel 10/11 application on PHP 8.2+. This package does not fit. Recommendation: do not adopt as a dependency. Evaluate two paths instead:

• Path A — buy: assess a Laravel-native JSON-RPC 2.0 server package (e.g. sajya/server is the most commonly cited candidate) against the conformance checklist below. Verify maintenance cadence, PHP 8.3 support, Laravel version constraints, and recent commit activity before committing.
• Path B — build thin: implement a first-party RpcDispatcher behind an interface. You gain full control over auth, validation, logging, and error mapping, and you avoid inheriting someone else's abandoned abstractions. Given the small spec surface, this is often the lower total-cost path.

Migration path. Two scenarios:

• Greenfield: skip this package entirely; no migration needed.
• Inherited dependency: contain it. Wrap all calls behind a single RpcDispatcher interface, pin the PHP version the code is known to run on, vendor the package into app/Support/Rpc rather than pulling from Packagist, and schedule replacement within one or two quarters as a tracked tech-debt item. Do not let new methods be added against the legacy path.

Compatibility. Unverified and likely broken on PHP 8.x; Symfony 4/5 constraints will conflict with a modern Laravel composer.lock; Laravel's container can bind the plain handler classes but cannot execute bundle compiler passes, so method auto-discovery must be reimplemented manually. Treat every one of these as work you own.

Sequencing.

1. Confirm the protocol requirement and inventory actual consumers (answers to the key questions above).
2. Build a minimal Laravel endpoint handling three representative methods end-to-end, including auth.
3. Run a conformance pass against the spec: parse error -32700, invalid request -32600, method not found -32601, invalid params -32602, internal error -32603; correct id echo semantics; notifications return no body; batch returns an array with per-item results and an empty array for an all-notification batch.
4. Decide build vs. buy based on the spike, not on the README.
5. Ship behind a feature flag with request/response logging and per-method latency metrics.

Operational Impact

Maintenance. Archived status means the maintenance burden transfers entirely to your team, permanently. Every PHP minor upgrade, every Laravel major upgrade, and every transitive-dependency CVE becomes your incident. Budget for this as a recurring cost, not a one-time integration task — this is the most common TPM miscalculation with abandoned packages.

Support. No maintainer, no issue triage, no security advisories. With zero dependents there is effectively no peer knowledge base; onboarding a new engineer means they read the source. That is acceptable for 400 lines of readable PHP; it is not acceptable for something masquerading as framework infrastructure.

Scaling. JSON-RPC over HTTP is stateless and scales exactly like any other PHP endpoint — the package is not the bottleneck. Two exceptions deserve explicit design attention: batch requests turn N logical calls into one long-lived PHP worker, risking gateway timeouts and worker-pool exhaustion (cap batch size, e.g. 20, and return a structured error above that); and payload size, which should be bounded at the ingress/gateway layer alongside any existing request-size limits.

Failure modes to instrument for.

• Silent spec non-compliance — wrong error codes or responses sent for notifications. External clients break subtly and debugging is miserable. Mitigate with an automated conformance suite in CI.
• Exception leakage — uncaught exceptions serialized into the JSON response, exposing stack traces and internal paths. Enforce a global catch that maps to -32603 with a correlation ID and no payload detail.
• Batch partial failure — one bad item must not fail the whole array; verify per-item error isolation.
• Over-exposure — with annotation- or tag-based method discovery, it is easy to publish a method that was never meant to be public. Require an explicit allowlist and an auth check bound to each method.
• Parameter binding ambiguity — named vs. positional params handled inconsistently across methods produces client-specific bugs.

Ramp-up. Low for a mid-level Laravel developer to use an equivalent implementation (half a day to first working endpoint). Moderate-to-high for anyone who must debug, port, or extend this package, because they must first learn Symfony bundle conventions — compiler passes, tagged services, HttpKernel sub-requests — for a system with no living community to consult. Realistic estimate: 1–2 weeks for the spike and decision, 2–3 weeks to productionize a replacement with conformance tests, auth, and observability.

Recommendation. Reject on adoption. Score 0.0375 combined with archived status, zero dependents, and a Symfony/Laravel mismatch is a clear no-go. Use the source as a design reference at most, and direct the ~0.94 opportunity signal toward evaluating a maintained Laravel-native package or a small first-party implementation.