Rpc Common Laravel Package

Product Decisions This Supports

• Microservices Architecture: Enables standardized RPC communication between PHP-based services, reducing coupling and simplifying service-to-service interactions.
• API Versioning & Backward Compatibility: Facilitates structured RPC contracts, easing future API evolution without breaking dependent services.
• Legacy System Modernization: Provides a lightweight way to introduce RPC patterns into older PHP/Laravel monoliths, incrementally adopting microservices.
• Build vs. Buy: Avoids reinventing RPC protocols (e.g., gRPC, JSON-RPC) when PHP-native solutions suffice for internal tooling or low-latency needs.
• Roadmap for Distributed Systems: Justifies investment in RPC infrastructure if the product is scaling beyond monolithic boundaries (e.g., multi-region deployments, event-driven workflows).
• Observability & Debugging: Introduces logging capabilities (via 1.2.1 release), which can aid in monitoring RPC traffic, debugging failures, and tracking performance—critical for distributed systems.

When to Consider This Package

• Avoid if:
  • Your stack relies on non-PHP languages (e.g., Go, Node.js) for RPC-heavy services—interoperability will be limited.
  • You need high-performance RPC (e.g., financial trading systems) where gRPC or custom binary protocols outperform JSON-based RPC.
  • Your team lacks PHP/Laravel expertise—maintenance risk outweighs benefits for greenfield projects.
  • The package’s 2017 release date and lack of active maintenance (beyond minor updates like logging) conflicts with modern security/compliance needs (e.g., no CVE patches, no feature parity with modern tools).
  • You require scalable logging/observability—this update adds logging but may lack structured formats (e.g., JSON, OpenTelemetry) or retention policies.
• Consider if:
  • You’re building internal tools or B2B integrations where PHP is the dominant language.
  • Your RPC needs are simple (e.g., <10 services, no streaming) and don’t require advanced features like auth plugins, load balancing, or sophisticated observability.
  • You prioritize developer velocity over cutting-edge performance (e.g., prototyping or non-critical workflows) and can tolerate verbose logs as a trade-off for basic debugging.
  • You’re willing to extend or fork the package to address gaps (e.g., structured logging, security hardening).

How to Pitch It (Stakeholders)

For Executives: "This package now includes basic logging for RPC calls, which helps us monitor and debug service interactions—like adding a ‘black box recorder’ for our internal APIs. It’s still a lightweight, PHP-native solution to avoid reinventing RPC wheels, but we’d need to pair it with modern observability tools (e.g., ELK, Datadog) to make it production-ready. Low-risk for now, but we should plan to upgrade or replace it if we scale beyond simple use cases."

For Engineering: *"The 1.2.1 update adds logging for RPC calls, which is a step up for debugging but comes with caveats:

• Pros: Easier to trace requests/responses across services (e.g., debugging a failed order sync).
• Cons:
  • Logs may be unstructured (no schema, high verbosity)—could bloat storage.
  • No built-in retention/alerting; we’d need to integrate with a logging pipeline.
  • Still unmaintained upstream; we’d need to fork or supplement with ReactPHP/Spatie for long-term use. Recommendation: Use this for low-stakes RPC (e.g., internal tools) where logs are a nice-to-have, but avoid for critical paths until we invest in a modern alternative (e.g., gRPC + OpenTelemetry)."*