Product Decisions This Supports
- Build vs. buy (buy, but wrap): An HTTP client is commodity infrastructure — nobody should be building one. The real decision is which client to standardize on and how tightly to couple to it. This package is a candidate only if your stack is Swoole-based; otherwise it's a novelty, not a strategy.
- Swoole/coroutine migration roadmap: The package's genuine differentiator is a single chainable API that runs on both native Curl (classic PHP-FPM) and Swoole coroutines. That directly supports a decision like "can we migrate service X to a coroutine runtime without rewriting its outbound HTTP layer?" — a real cost line in any Swoole/Hyperf/OpenSwoole adoption plan.
- Feature work it unblocks cheaply: third-party API aggregation, webhook fan-out, bulk download/upload jobs, proxy-aware scraping/ingestion pipelines, and internal service-to-service calls where Guzzle's overhead or coroutine incompatibility is the blocker.
- Architecture standardization: whether to mandate one HTTP client across the codebase, or permit per-runtime clients behind a shared interface. This package argues for the latter (see below).
- Risk appetite decisions: 261 stars, zero Packagist dependents, docs and community support (QQ group) primarily in Chinese. That is an adoption decision, not a technical one — it sets your bus-factor and vendor-continuity exposure for a component that touches every outbound call.
- Explicitly does not support: any decision about PSR-18/PSR-7 interoperability, long-term enterprise support, or security-response SLAs. Those require guarantees the project does not publish.
When to Consider This Package
Consider it when:
- You run (or are actively migrating to) Swoole/OpenSwoole/Hyperf and need an HTTP client that behaves identically in coroutine and non-coroutine contexts.
- You want a lower-ceremony chainable API than Guzzle for straightforward request/response work, with cookie, redirect, proxy, and file-transfer handling built in.
- You need high-concurrency outbound calls (fan-out to many upstreams) where coroutine-native I/O is the performance lever.
- Your team reads Chinese comfortably, or the surface area you use is small enough that docs language is irrelevant.
Look elsewhere when:
- Your runtime is standard PHP-FPM and nothing on the roadmap requires coroutines — Guzzle or Symfony HttpClient are the default, and the switching cost buys you nothing.
- You require PSR-18/PSR-7 compliance, because you rely on middleware, mocking, or framework integration built around those interfaces.
- You need a broad hiring pool, Stack Overflow answers, and a large body of integration examples — Guzzle wins decisively there.
- Your risk tolerance for low-adoption dependencies is low: zero dependents means no visible third-party production validation, and no evidence of a coordinated security-disclosure process.
- You need commercial support, an SLA, or a named maintainer commitment. MIT gives you the right to fork, not the capacity to.
Diligence before adoption: verify release cadence and issue-response time (the listed release date looks anomalous — confirm against the repository), confirm PHP version support, and check whether the Curl and Swoole backends are equally maintained, since the coroutine path is the only reason to pick this over the default.
How to Pitch It (Stakeholders)
For executives: This is a zero-license-cost, MIT-licensed PHP HTTP client. It is not a platform bet — it's a tactical component. Its one strategic angle is that it lets us make high-concurrency outbound HTTP calls under Swoole without rewriting our request code, which is a measurable schedule saving if coroutine migration is on the roadmap and a non-factor if it isn't. The risk is maintenance continuity: the project is small, with limited public adoption, so we should treat it as a component we may need to maintain ourselves rather than one we can lean on a vendor for. Cost of adoption is low; cost of exit is low if we isolate it — so the recommendation is to pilot it behind an internal interface, not to standardize on it.
For engineering: One API, two backends — native Curl for classic PHP, coroutine-native for Swoole — with chaining for headers, cookies, redirects, proxies, and streaming transfers. That means no branching in business code between runtimes. Adopt it pinned to an exact version, behind a thin internal HttpClient interface (or a PSR-18 adapter), so we can swap to Guzzle or Symfony HttpClient without touching call sites. Instrument p95 latency, error rate, and memory under concurrency from day one. Budget a small fork-and-patch capability: given the project's size, assume we may need to carry a patch or take over maintenance for the paths we depend on.
Recommendation: Approve a scoped pilot in one Swoole service. Do not adopt as the house standard. Revisit if adoption signals, release cadence, or our coroutine footprint change materially.