Prowl Bundle Laravel Package

Product Decisions This Supports

• Channel scoping for internal alerting: Decides whether iOS push via Prowl is an acceptable mechanism for low-volume, non-customer-facing notifications — cron failures, deploy status, incident escalation, admin/ops alerts — rather than a user-facing notification platform.
• Build vs. buy vs. borrow-the-pattern: Frames the real choice as (a) adopt a dependency, (b) integrate the underlying xenji/prowlphp library behind a Laravel-native channel, or (c) build a thin Http-based channel in-house. For a Laravel product the honest answer is (b) or (c); this repo is a specification sketch, not an installable package.
• Roadmap prioritization and effort sizing: Positions the work as a half-day to two-day utility, not a roadmap initiative. That sizing is itself a decision input — it should never compete with revenue-facing work for a sprint slot, and it should never be deferred indefinitely if ops alerting is currently email-only and ignored.
• Provider strategy and exit planning: Forces an explicit decision on whether Prowl remains a supported channel at all, and what the successor is (Pushover, ntfy, direct APNs, in-app inbox). Prowl is a legacy single-vendor service with an aging iOS client and no meaningful SLA; any product dependency on it is strategic exposure independent of wrapper quality.
• Legacy estate decisions: If the org still runs Symfony2 applications, this informs keep-vs-retire for those integrations. If the org is Laravel-only, it is a clean "no" and closes the question.
• Abstraction investment: Supports mandating a provider-agnostic notification interface and config-driven channel selector as a hard requirement — the one design decision here that survives the vendor.
• Risk triage: Low stars (8), zero dependents, Symfony2 vintage, and no release cadence are a reliable composite signal that no one else is absorbing the maintenance. Score 0.04 is consistent with a dead artifact.

When to Consider This Package

Consider it (as reference, not dependency) when:

• You are maintaining a legacy Symfony2 application and need a quick, MIT-licensed wrapper around ProwlPHP for internal iOS push — the only context where the bundle format is actually an asset.
• You need a compact, authoritative list of integration knobs — API key, provider key, application name, priority defaults, endpoint shape, response codes. The bundle's DependencyInjection/Configuration.php and Resources/config/services.yml are a usable blueprint for writing your own Laravel service provider and channel.
• The use case is low-volume, internal, non-critical alerting where fire-and-forget delivery and iOS-only reach are acceptable, and you can tolerate best-effort support.
• You want to validate Prowl end-to-end quickly before committing to a migration — read the intent, send one real notification, confirm key, egress, and priority handling.

Look elsewhere (or do not adopt) when:

• You are on modern Laravel. It pins Symfony 2.x components and ships a Bundle subclass with a DI container registration model Laravel does not have — no service provider, no facade, no publishable config, no extra.laravel block. Composer will not resolve it alongside Laravel's Symfony 6/7 tree, and forcing it via --ignore-platform-reqs or a replace shim drags an unmaintained Symfony 2 container into production. That is a hard no.
• You need PHP 8+ / Symfony 5+, active maintenance, security response, or a CVE stream. There is none.
• You need multi-channel notifications, delivery guarantees, or receipts. Prowl offers only a synchronous response, and it returns HTTP 200 with an error body for several failure classes — naive integration loses notifications silently.
• You need volume. Prowl enforces a per-provider-key hourly cap (historically 1,000), returns 503-class responses when exceeded, and offers no batching or digest. With a single shared key, one noisy tenant starves everyone.
• You need vendor support or a contractual SLA. Prowl is a legacy one-person push service; App Store removal or shutdown is total, unrecoverable channel loss.

How to Pitch It (Stakeholders)

Executive summary: This is a small, MIT-licensed Symfony2 wrapper around Prowl, an iOS push notification service. It is not a Laravel package and will not install into our stack — it pins Symfony 2.x dependencies that conflict with modern Laravel. Its only real value to us is as a design blueprint: a dozen configuration keys and one API call. The underlying capability is one HTTP POST with five form fields, which Laravel's Http facade and a queued job cover natively. Adoption signal is weak — 8 stars, zero dependents, no release cadence. Recommendation: do not adopt as a dependency. Spend roughly half a day reimplementing the intent as a Laravel-native, queued notification channel. Separately, treat the decision about whether Prowl remains a supported channel at all as its own tracked initiative — the vendor risk is larger than the wrapper risk.

Engineering summary: Treat the repository as documentation. Read DependencyInjection/Configuration.php for the config surface and Resources/config/services.yml for wiring, then build an internal ProwlChannel implementing Laravel's notification contract, with config/prowl.php for api_url, api_key, application, priority, timeout, and queue. Use Http::asForm()->timeout(5)->retry(3, 200, throw: false) instead of curl, dispatch from a ShouldQueue notification so web requests never block on a third-party POST, and explicitly map Prowl's response codes — 200 success, 400 bad request, 401 invalid key, 406 not approved, 409 not registered, 500/503 server or rate limit — into log events and a metric. Put the channel behind an interface with a config-driven provider selector, route through a RateLimiter, partition keys per tenant where possible, and drop non-critical priorities first under throttle. Keys belong in a secrets manager, not a checked-in .env; the key is the sole credential and there is no per-message revocation, so document rotation. Net engineering cost is a few dozen lines, and it eliminates the entire dependency-graph problem. The abstraction is the highest-value decision here — it is the only thing that survives the vendor, and it should be treated as a hard requirement, not a nice-to-have.