Jsonrpc Params Symfony Validator Sdk Laravel Package

Technical Evaluation

Architecture fit

• This package is a narrow adapter, not a framework. It implements the params-validation contract from the yoanm/jsonrpc-* family by delegating to symfony/validator. Its only job is: accept JSON-RPC params plus a validation rule/constraint set, run Symfony Validator, and surface violations back to the JSON-RPC server layer (ideally as -32602 Invalid params).
• Fit inside a Laravel codebase is therefore conditional. It is a good fit only if we are also adopting yoanm/jsonrpc-server-sdk (or the params-validator interface package) to expose an actual JSON-RPC endpoint. For a conventional Laravel REST/Inertia application it introduces a second, parallel validation stack alongside Illuminate\Validation, with no shared error format, no FormRequest integration, and no Blade/Inertia error-bag benefits.
• The clean architectural role is a boundary adapter: JSON-RPC transport → params validator → domain service. Keep it behind an internal interface so the domain layer never depends on the vendor namespace.

Integration feasibility

• Composer installation is trivial (MIT, standard PSR-4). Laravel's container will autowire the class provided its constructor dependencies are type-hinted concretes or bound interfaces.
• The real work is bootstrapping: Symfony Validator needs a ValidatorBuilder with metadata loaders (attributes/YAML/XML), a cache pool for metadata, and a binding for Symfony\Component\Validator\Validator\ValidatorInterface. That is a ~50-line service provider plus a config file.
• No known conflict with Laravel's own validator; both can coexist. The main resolution risk is Symfony component version constraints pinned by illuminate/*.

Technical risk

• Adoption/vendor risk is the dominant risk: 1 star, 0 dependents, single-maintainer lineage, score 0.365. Recent release (2025-09-03) is reassuring but does not indicate a community.
• Silent-validation risk: if constraint metadata is not loaded correctly (wrong loader, missing attribute autoload, mis-scoped cache), the validator can pass everything. In a params boundary this is a security-relevant failure, not just a bug.
• Semantic drift risk: Symfony constraints differ from Laravel rules (nested/array handling, Valid cascade, group sequencing, message formatting). Engineers will need discipline to avoid mixing the two idioms.
• Scope risk: the package is tiny; most behavior lives in the upstream interface package and in our own wiring. We will own the integration code regardless.

Key questions

1. What is the exact transitive dependency set — does it require yoanm/jsonrpc-params-validator-sdk interfaces and a specific server SDK major version?
2. Which Symfony Validator majors (6.4 / 7.x) and PHP versions are supported in the current release?
3. How are violations mapped to JSON-RPC error objects — does the package return violations, and who translates them to -32602 with data?
4. Are constraints supplied as attributes on DTOs, as rule objects, or as arrays? This determines how much boilerplate each RPC method carries.
5. Is nested/array params validation supported, and is there test coverage we can trust?
6. What is the upstream maintenance signal — commit cadence, issue responsiveness, willingness to accept PRs?

Integration Approach

Stack fit

• Target: Laravel 10–12, PHP 8.2+, Composer, optional PSR-6/PSR-16 cache. Fits cleanly as an internal JSON-RPC endpoint (service-to-service or partner API) mounted on a dedicated route group, not as a replacement for existing HTTP controllers.
• If the product has no JSON-RPC surface, the correct decision is do not adopt; use Illuminate\Validation and note this package as evaluated-and-rejected.

Migration path

1. Introduce a dedicated /rpc route group and a single controller that hands off to yoanm/jsonrpc-server-sdk.
2. Add this validator as the params-validation strategy; register Symfony Validator in a JsonRpcServiceProvider with an explicit metadata cache pool.
3. Build a small error mapper from Symfony ConstraintViolationListInterface to the JSON-RPC error payload (code -32602, data.violations[]).
4. Wrap the vendor validator in an internal RpcParamsValidator interface; the vendor class is an implementation detail.
5. Leave all existing FormRequest/REST validation untouched. Migration is additive, per-method, reversible.

Compatibility

• Verify Composer resolution against Laravel's pinned Symfony components (translation, http-foundation, etc.). A symfony/validator requirement of ^6.4 || ^7.0 is the expected happy path; anything narrower should be flagged.
• Confirm PHP attribute support if constraints are attribute-based (PHP 8+ required, fine on our floor).
• No Laravel facade, config publishing, or queue integration — all wiring is ours.

Sequencing

• Week 1: timeboxed spike (1–2 days) proving install, container binding, one validated method, and one failing method returning -32602. Decision gate: does the vendor interface model match our DTO style?
• Week 2: service provider, PSR-6 metadata cache, error mapper, contract tests (valid, invalid, nested, missing, extra params).
• Week 3: roll out per RPC method behind feature flags; document constraints conventions for the team.
• Ongoing: quarterly dependency review.

Operational Impact

Maintenance

• Code surface is small, but we own the wiring, the error mapping, and the upgrade path. Pin the exact version, commit the lockfile, and subscribe to upstream releases.
• Because it is MIT and tiny, a fork-and-vendor contingency is cheap (~a day) if the project is abandoned. Keep the internal interface boundary to make that swap a one-file change.
• Track Symfony Validator majors; that upgrade, not this package, will drive most maintenance work.

Support

• Community support is effectively nil at 1 star / 0 dependents. Internal ownership is mandatory; there is no vendor to escalate to.
• Most questions resolve against Symfony Validator documentation rather than this repo. Onboarding docs should state that explicitly.
• Budget a named owner (one backend engineer, part-time) for dependency and security patching.

Scaling

• Validation is CPU-bound and per-request, stateless, and horizontally scalable. Cost is comparable to Laravel validation for equivalent rule complexity.
• Metadata caching is the scaling lever: without a PSR-6 cache pool, constraint metadata is rebuilt per request and will dominate latency on high-RPC-volume endpoints. Wire it to the Laravel cache store from day one.
• Memory footprint is negligible; no connection pools, no I/O beyond cache.

Failure modes

• Unhandled ValidationFailedException bubbling to the framework → HTTP 500 instead of a JSON-RPC error. Mitigate with a global exception renderer scoped to the RPC route group.
• Metadata loader misconfiguration → constraints silently not applied (validation bypass). Mitigate with negative contract tests asserting invalid payloads are rejected.
• Cache poisoning or stale metadata after a constraint change → old rules enforced. Mitigate with versioned cache keys tied to deployment.
• Version drift between this package and the server SDK → signature/type errors at container resolution. Mitigate with lockfile pinning and a smoke test in CI.
• Verbose violation messages leaking internal field names or structure. Mitigate with a response-shaping layer.
• Extra/unexpected params accepted by default. Confirm the server SDK's strictness; add explicit rejection if the contract requires it.

Ramp-up

• A Laravel engineer familiar with Symfony Validator needs roughly half a day to be productive; someone only familiar with Illuminate\Validation needs 1–2 days plus a written conventions note.
• Friction is conceptual, not technical: two validation idioms in one codebase. Publish a one-page rule ("REST → FormRequest; RPC → Symfony constraints") and enforce it in review.
• Overall TPM recommendation: conditional adopt — pursue only if a JSON-RPC surface is already on the roadmap; otherwise close the evaluation and standardize on Laravel's validator.