Plugin Log Laravel Package

Product Decisions This Supports

• Debugging & Observability: Enables structured logging of HTTP requests/responses in Guzzle (v3), critical for debugging APIs, monitoring latency, or validating payloads in production/debug environments.
• Compliance & Auditing: Logs can be used to track API usage patterns, validate data integrity, or meet regulatory requirements (e.g., GDPR, HIPAA) by capturing request/response metadata.
• Performance Optimization: Identifies bottlenecks by logging request times, status codes, or payload sizes, informing infrastructure or API contract changes.
• Cost Control: Logs can flag excessive API calls or large payloads, helping optimize cloud/API spend (e.g., AWS Lambda, Stripe).
• Build vs. Buy: Avoids reinventing logging middleware for Guzzle, reducing dev time and technical debt. Preferable over custom solutions if Guzzle v3 is already in use.
• Roadmap Prioritization: Justifies investment in observability tools (e.g., ELK, Datadog) by ensuring raw HTTP data is loggable before enrichment.

When to Consider This Package

• Use This If:

  • Your stack uses Guzzle v3 (incompatible with v6/7; see guzzlehttp/guzzle for modern alternatives).
  • You need low-level HTTP logging (headers, bodies, metadata) without modifying core Guzzle logic.
  • Your team prioritizes debugging over production-grade logging (e.g., no PII masking, minimal overhead).
  • You’re working with legacy systems where upgrading Guzzle isn’t feasible.

• Look Elsewhere If:

  • You’re on Guzzle v6/7: Use guzzlehttp/guzzle with middleware (e.g., GuzzleHttp\Middleware::tap()).
  • You need structured logging (JSON, correlation IDs): Pair with monolog/monolog or react/promise for async processing.
  • Performance is critical: This adds ~5–10% overhead per request; consider sampling or async logging.
  • You require production-ready logging: Missing features like rate limiting, log rotation, or sensitive data redaction.
  • Your team uses alternative HTTP clients (e.g., Symfony HTTP Client, cURL directly).

How to Pitch It (Stakeholders)

For Executives: "This lightweight package lets us log all HTTP traffic from our Guzzle v3 clients—critical for debugging API issues, auditing usage, and optimizing costs. For example, we can track failed payments (Stripe) or slow third-party calls (Twilio) without adding engineering overhead. It’s a low-risk way to gain visibility into our API interactions, justifying future investments in observability tools like Datadog. Since it’s maintained by the Guzzle team (even if unstarred), it’s a safe bet for our legacy stack."

For Engineers: *"If we’re stuck on Guzzle v3, this is the easiest way to log raw HTTP requests/responses. It’s a single middleware addition:

$client = new Guzzle\ServiceClient(['plugins' => ['log']]);

Pros:

• Zero config for basic logging (outputs to stderr by default).
• Works with existing Guzzle plugins (e.g., OAuth). Cons:
• Guzzle v3 only—don’t use for new projects.
• No built-in filtering or enrichment (you’ll need Monolog or similar).
• Minimal community activity (but stable, as it’s a subtree split).

Recommendation: Use this for debugging, then layer on Monolog for production. If you’re on v6/7, skip this and use Guzzle’s middleware API instead."*

For Data/Compliance Teams: *"This package captures metadata (headers, status codes, timestamps) for all HTTP calls, which we can use to:

• Audit API usage patterns (e.g., ‘Why did this payment fail?’).
• Validate data integrity (e.g., ‘Did the webhook payload match the DB?’).
• Meet compliance needs (e.g., ‘Log all external API calls for 90 days’). Caveat: Logs are raw—you’ll need to process them (e.g., with ELK) to filter PII or sensitive data."*