Sdk Core Laravel Package

Product Decisions This Supports

• Build vs. Buy: Accelerates adoption of a privacy-first, EU-hosted error-tracking solution (vs. building in-house log aggregation or relying on US-based alternatives like Sentry). Reduces dev time for compliance-heavy industries (e.g., healthcare, fintech).
• Roadmap: Enables structured logging (PSR-3) and error tracking in a unified pipeline, simplifying migration from disparate tools (e.g., Monolog + Sentry). Aligns with trends toward observability consolidation.
• Feature Parity: Justifies dropping legacy logging stacks (e.g., custom Monolog handlers) in favor of a batteries-included SDK with:
  • Automatic OOM/fatal error capture (no manual set_error_handler).
  • Breadcrumbs/scopes for debugging user flows (reduces context-switching in support tickets).
  • Worker-aware delivery (critical for PHP 8.3+ async workers like Swoole/RoadRunner).
• Use Cases:
  • Compliance: GDPR/CCPA scrubbing built-in (avoids manual PII redaction).
  • Performance: ClickHouse-backed aggregation reduces query costs vs. self-hosted ELK.
  • Debugging: Structured logs + error tracking in one place (replaces ad-hoc error_log() + third-party tools).

When to Consider This Package

• Adopt if:
  • Your stack is PHP 8.3+ (hard dependency; no backports planned).
  • You need EU-hosted logging (avoiding US data sovereignty risks).
  • Your team uses PSR standards (or is willing to adopt them for logging).
  • You’re already using or evaluating AppLogger’s platform (this is the core SDK).
  • Your app runs in non-trivial PHP environments (workers, FastCGI, CLI) where error handling is fragile.
• Look elsewhere if:
  • You require sub-millisecond latency for log delivery (this is async; not for real-time dashboards).
  • Your team resists PSR-3 adoption (package enforces it via LoggerInterface).
  • You need native support for non-PHP services (e.g., Node.js/Python; this is PHP-only).
  • Your budget allows for Sentry/SentryOne (more mature, but US-hosted).
  • You’re heavily invested in self-hosted (e.g., Loki/Grafana) and want to avoid vendor lock-in.

How to Pitch It (Stakeholders)

For Executives: "This SDK lets us replace fragmented logging/error tools with a single, privacy-compliant solution hosted in the EU—reducing vendor risk and dev overhead. It’s designed for modern PHP (8.3+) and handles edge cases like OOM errors automatically, cutting debugging time. Since it’s framework-agnostic, we can standardize across Symfony/Lumen/CLI apps without rewrites. Early adopters in healthcare/finance use it to avoid US data transfers; we could too for ~$X/month vs. building this ourselves."

For Engineering: *"This is a drop-in replacement for Monolog + Sentry:

• No more manual error handlers: Catches fatals/OOMs via shutdown hooks.
• Structured logs out of the box: PSR-3 compatible, so your existing Monolog code works.
• Worker-friendly: Auto-detects Swoole/RoadRunner and flushes logs correctly.
• GDPR scrubbing: Built-in PII redaction (no more str_replace hacks).
• Lightweight: MIT-licensed, no runtime exceptions, and async delivery won’t block requests. Tradeoff: Tied to AppLogger’s platform, but their ClickHouse backend is cheaper than self-hosted ELK for our scale."*

For Security/Compliance: *"This solves two pain points:

1. EU hosting: Avoids US data sovereignty issues (critical for [regions]).
2. Automatic scrubbing: Uses AppLogger’s GDPR-compliant pipeline to redact PII—no manual rules needed. Risk: Vendor lock-in, but their MIT-licensed SDK means we could fork if needed."*