Json Rpc Log Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for RPC observability. tourze/json-rpc-log-bundle is a logging/telemetry add-on for JSON-RPC traffic. The decision it informs is whether to hand-roll request/response logging middleware (interceptors, correlation IDs, redaction, retention) or adopt a package that already wraps that concern.
• Debugging and support posture. Payload-level logs shorten the path from "customer reports a failed call" to "here is the exact JSON-RPC envelope." This is a support-cost and MTTR decision, not a feature decision.
• Protocol standardization. Choosing to adopt this package implicitly bets that JSON-RPC stays a first-class transport in your architecture (partner APIs, internal service calls, gateway-to-service hops). If JSON-RPC is a one-off integration, the package is not worth the dependency.
• Audit and compliance scoping. Logging raw RPC payloads is an auditability win and a data-handling liability at the same time. Adopting this forces an early decision on redaction, retention windows, and where logs land.
• Roadmap timing. The 2.0.0 major bump is a planning input: it signals an upstream breaking change that must be absorbed before the package can be baked into any committed roadmap item.

When to Consider This Package

Adopt-worthiness criteria:

• Your stack is genuinely PHP with a Laravel service provider or Symfony bundle lifecycle that matches what this package ships. Verify this first — the -bundle suffix and tourze/ namespace read as Symfony Bundle conventions, so confirm Laravel compatibility before it enters a design doc.
• JSON-RPC is a primary transport across more than one service boundary, so a shared logging component avoids duplicated middleware.
• You need structured, per-call logs (method, params, result, error, timing) rather than generic application logging.
• You can tolerate a community-scale package: sparse release notes, no formal support contract, and version churn.

Look elsewhere when:

• You need vendor-backed SLAs, security review artifacts, or a published support policy.
• OpenTelemetry, PSR-3/Monolog channels, or an existing APM already cover the need — adding a second logging path fragments your observability story.
• Traffic volume is high enough that synchronous payload logging becomes a latency or storage cost problem.
• You need first-class Laravel integration and cannot confirm this package's framework fit.

Critical caveat on 2.0.0: the only published note is a compare link. A major version with no migration guide, no breaking-change list, and no deprecation notes is a process maturity signal, not just a version number. Treat 2.0.0 as unvetted until the diff is read by an engineer. If you adopt now, pin to 1.0.2 and track 2.0.0 as a separate, budgeted upgrade task.

How to Pitch It (Stakeholders)

To executives: This is a low-cost observability component for JSON-RPC traffic. It buys faster incident diagnosis and cleaner audit trails without building custom logging middleware. The trade-off is a small, community-maintained dependency — so the ask is a time-boxed technical evaluation, not a permanent platform commitment. The 2.0.0 release shipped without release notes, which is why we are gating adoption behind an engineering review rather than rolling it out directly.

To engineering: A drop-in logging layer for JSON-RPC calls — captures envelope, method, timing, and errors in one place instead of per-service middleware. Two open questions before we commit: (1) confirm Laravel interoperability given the Symfony-style bundle packaging, and (2) review the 1.0.2...2.0.0 diff for breaking changes, since upstream published no migration notes. Recommendation: prototype on a non-critical service, pin the version explicitly, and verify payload redaction before any production traffic touches it.