Our Ray Laravel Package

Product Decisions This Supports

• Debugging & Observability Roadmap: Accelerates adoption of structured debugging in PHP/Laravel apps by integrating with Ray (a modern alternative to dd()/dump()) and ourray.app (a cloud-based Ray viewer). Aligns with initiatives to replace legacy var_dump()/Log::debug() with richer, searchable debugging.
• Build vs. Buy: Buy—avoids reinventing Ray-to-cloud sync logic. Spatie’s package abstracts authentication, payload formatting, and cloud routing, reducing dev time by ~80% compared to a custom solution.
• Use Cases:
  • Developer Experience (DX): Enable engineers to debug distributed Laravel apps (queues, APIs, cron jobs) without local Ray server setup.
  • Production Debugging: Ship debug payloads to a centralized dashboard (ourray.app) for post-mortems, with no PII exposure (configurable via .env).
  • Onboarding: Standardize debugging tools across teams by embedding Ray in new Laravel projects via composer.
  • Legacy Modernization: Gradually replace Log::debug() calls with our()->ray() for richer context (e.g., request IDs, stack traces).
• Cost vs. Value: Low-cost ($0 for MIT license) with high ROI for teams debugging microservices or serverless Laravel functions.

When to Consider This Package

• Adopt if:

  • Your team uses Laravel/PHP and relies on dd(), dump(), or Log::debug() for debugging.
  • You need cloud-based debugging (e.g., debugging Lambda functions, Kubernetes pods, or remote servers).
  • You’re evaluating Ray (from myray.app) but lack infrastructure to self-host the Ray server.
  • Your roadmap includes observability for distributed systems (e.g., queues, APIs, cron jobs).
  • You prioritize developer productivity over self-hosted debugging tools.

• Look elsewhere if:

  • You’re not using Laravel/PHP (package is Laravel-specific).
  • You require self-hosted Ray (e.g., for compliance/offline use) or need advanced features like query recording (use spatie/laravel-ray instead).
  • Your debugging needs are simple (e.g., only var_dump() is used).
  • You’re already using a commercial APM (e.g., New Relic, Datadog) with built-in PHP debugging—this is a lightweight alternative.
  • Your team lacks cloud access (ourray.app requires internet connectivity).

How to Pitch It (Stakeholders)

For Executives (Business/Tech Leads)

*"This package lets our Laravel engineers debug distributed systems in production—without self-hosting tools or context-switching to local logs. By integrating Ray (a modern dd() replacement) with ourray.app, we can:

• Reduce MTTR: Debug failures in queues, APIs, or cron jobs via a cloud dashboard (no SSH needed).
• Cut costs: Avoid maintaining a Ray server (~$0 vs. ~$500/year for a self-hosted instance).
• Standardize DX: Replace ad-hoc var_dump() with structured debugging, improving onboarding.
• Scale observability: Works seamlessly with serverless/Lambda, Kubernetes, and multi-region apps.

Ask: Should we pilot this for our [highest-pain debugging scenarios]? Budget: $0 (MIT license)."*

For Engineering (Devs/Architects)

*"Problem: Debugging Laravel apps in production is slow—logs are scattered, dd() breaks flows, and self-hosting Ray adds ops overhead.

Solution: spatie/our-ray lets you:

• Replace dd() with our()->ray()—payloads auto-sync to ourray.app.
• Debug anywhere: See request context, stack traces, and variables in a unified dashboard.
• Zero setup: No Ray server to maintain; works out-of-the-box with Laravel.
• Lightweight: ~50 lines of code to integrate (vs. hours for a custom solution).

How to start:

1. Add to composer.json: composer require spatie/our-ray.
2. Configure .env (API key from ourray.app).
3. Replace dd($var) with our()->ray($var).

Tradeoffs:

• Pros: Cloud-based, no infra, rich payloads.
• Cons: Requires internet (not for air-gapped systems).

Next steps: Let’s test this in [Project X]—focus on debugging [specific pain point]."*