Product Decisions This Supports
- Log-pipeline architecture (build vs. buy vs. glue): Forces the explicit decision of whether log shipping is a blocking or non-blocking concern in the request path. This package represents the "small, purpose-built adapter" option — a thin async HTTP client for pushing log payloads to a collector without stalling the response.
- Latency budget allocation for observability: Quantifies the cost of synchronous remote log handlers. If shipping logs over HTTP inline adds 5–50 ms per request, this package is a lever for reclaiming that budget in high-throughput endpoints.
- Runtime standardization: Choosing this package effectively commits the team to a Workerman-based runtime (webman, GatewayWorker, or a Workerman process embedded alongside Laravel). That is a platform decision, not a logging decision, and should be evaluated at the roadmap level.
- Vendor consolidation: Whether to adopt a single logging stack (Monolog handlers + a collector like Vector/Fluent Bit/OTel Collector) versus maintaining bespoke per-service async adapters.
- Internal tooling vs. product dependency: Reasonable candidate for internal/back-office services where blast radius is small; not a candidate for customer-facing revenue paths without a fork-and-own commitment.
- Deprecation/technical-debt triage: With no release since February 2021, zero stars, and zero dependents, adopting it is itself a roadmap item — you are taking on maintenance. That should be costed, not discovered later.
When to Consider This Package
Adopt only when all of these hold:
- You are already running Workerman in production (webman, GatewayWorker, or a Workerman sidecar) and the event loop is available — the async HTTP client is meaningless outside that runtime.
- Your PHP version is pinned to something the 2021-era dependency tree supports (realistically PHP 7.x); verify against
workerman/http-client and Workerman core versions before assuming PHP 8.x compatibility.
- Log delivery is best-effort and loss-tolerant — async fire-and-forget means no backpressure, no delivery guarantee, and silent drops when the collector is down or the process exits with an in-flight buffer.
- You are prepared to vendor or fork: pin the commit, read the whole (~small) codebase, add tests, and own it. There is no upstream to lean on.
- The alternative is materially worse — e.g., the only current option is a blocking cURL call inside a hot loop.
Look elsewhere when:
- You are on Laravel Octane, Swoole, RoadRunner, or plain FPM. Use Monolog handlers with an async/buffered wrapper, or ship to a local agent (Vector, Fluent Bit, OTel Collector) and let the agent handle the network. This removes the in-process async complexity entirely.
- You need delivery guarantees, retries, backoff, disk spooling, or sampling. Monolog + a real transport does this; this package does not appear to.
- You need PHP 8.1+, static analysis, security review sign-off, or an SBOM with maintained dependencies. An unmaintained package with zero dependents is a supply-chain liability.
- You need first-class observability — structured logs correlated to traces/metrics. OpenTelemetry's PHP SDK is the strategic direction; a bespoke HTTP log shipper is a dead end.
- You are a small team with no capacity to own a fork. In that case the honest answer is: pay the small latency cost, or deploy a local collector agent.
How to Pitch It (Stakeholders)
To executives (one line): A narrowly scoped, unmaintained open-source adapter that lets Workerman-based PHP services ship logs over HTTP without blocking responses — low cost to try, but it comes with ownership risk and is not a strategic observability investment.
To engineering leadership: This is a tactical optimization, not a platform. It solves one real problem — synchronous remote logging inflating request latency in an event-loop runtime — and it solves it in roughly one file's worth of code. The dependency has had no release since February 2021, zero stars, and zero known dependents, which means: no security response, no PHP 8 assurance, and no community. Recommendation is to treat it as a reference implementation rather than a dependency — read it, then either (a) copy the ~100 lines into an internal package we own, or (b) skip it and route logs through a local collector agent (Vector/Fluent Bit/OTel), which solves the latency problem with better operability, backpressure, and delivery guarantees.
Decision requested: Approve or reject the internalization. If we adopt it as-is, we accept a maintenance line item and a runtime coupling to Workerman; if we internalize it, cost is a few engineering days and we gain testability and PHP 8 support. I recommend internalizing or routing through a local agent — not adding the dependency.
Bottom line for the roadmap: Do not place this on a critical path. It is a candidate for a small internal utility behind an interface, so the transport remains swappable when we move to OpenTelemetry.