Server Laravel Package

Product Decisions This Supports

• API style selection (RPC vs. REST/GraphQL): Sajya Server is a JSON-RPC 2.0 server for Laravel. Adopting it is a deliberate architectural bet that your consumers want method-oriented, single-endpoint calls (ideal for internal service-to-service traffic, mobile clients on poor networks, and action-heavy backends) rather than resource-oriented REST.
• Build vs. buy on protocol plumbing: The package owns the boring-but-error-prone parts of the spec — request/response envelopes, batch requests, error codes, notification handling, and parameter validation wired into Laravel's validator and container. Buying this is typically weeks of avoided work plus ongoing spec-compliance risk; building it in-house rarely becomes a differentiator.
• Roadmap unblocking / framework currency: The 7.1.0 release adds Laravel 13.x compatibility. This directly supports a "stay on the supported Laravel track" roadmap commitment and removes the package as an upgrade blocker for the framework upgrade epic.
• Feature scoping: Procedure-level design (one class or closure per callable method) maps cleanly onto domain capabilities, making it easy to scope, version, and deprecate individual procedures without touching the transport layer.
• Operational risk modeling: 7.1.0 is a low-risk release — no breaking changes, no deprecations, no behavioral changes to the wire format. The only functional change (attribute retrieval via IS_INSTANCEOF) is an internal correctness fix to how procedure metadata is resolved, which reduces edge-case risk for teams using attribute-based configuration.
• Batch endpoint use cases: Batch request support in the spec is a strong fit for reducing round trips in mobile/offline-first clients and for aggregate "dashboard" endpoints that would otherwise fan out into many REST calls.

When to Consider This Package

Adopt when:

• Your API is naturally verb/action-shaped (commands, calculations, multi-step operations) and REST resource modeling would produce awkward noun endpoints or excessive custom actions.
• You need strict JSON-RPC 2.0 conformance, including batch requests, notifications, and standardized error objects — and you'd rather not hand-roll it.
• You're on Laravel (now supported through 13.x) and want procedures to reuse existing validation rules, middleware, auth guards, and the service container.
• Your consumers are first-party or contract-bound clients that can be generated against a method list, rather than a broad public developer ecosystem expecting REST + OpenAPI.
• You want a small, single-responsibility dependency that won't drag in a large transitive surface.

Look elsewhere when:

• Your public API strategy depends on HTTP semantics, caching, CDN behavior, or OpenAPI/tooling ecosystems — choose REST or JSON:API instead.
• You need streaming, server push, or subscriptions (WebSockets/SSE); JSON-RPC over HTTP request/response is not that.
• You require strong release cadence guarantees or a commercial support contract — note that recent release content is largely Dependabot CI bumps plus framework-compatibility work; the project is healthy but lean. Treat it as community-maintained and pin versions.
• You're not on Laravel, or you need protocol-agnostic RPC with code generation across many languages — a gRPC/Connect stack may fit better.
• You need graph-shaped reads with client-specified field selection; that's GraphQL's job.

How to Pitch It (Stakeholders)

To executives: This is a small, focused library that gives us a standards-compliant JSON-RPC 2.0 API surface on top of Laravel, so we can ship internal and client-facing operations quickly without inventing our own request/response contract. The 7.1.0 release adds Laravel 13 support, which clears a blocker on our framework upgrade and carries no breaking changes — a safe, low-cost dependency that keeps our platform on a supported version.

To engineering: 7.1.0 is effectively maintenance-plus-compatibility: CI action bumps, confirmed Laravel 13.x support, and one internal correctness improvement switching attribute retrieval to IS_INSTANCEOF (better handling of attribute-based procedure metadata). No migration work, no API changes. We pin the version, upgrade alongside the framework bump, and keep our procedures thin — business logic stays in our own service classes so the package remains a replaceable transport layer rather than a place where domain logic accumulates.