Yurun Http Laravel Package

Technical Evaluation

Architecture fit. YurunHttp is a standalone, framework-agnostic HTTP client with a fluent/chained API and pluggable drivers (Curl for classic FPM/CLI, Swoole for coroutine contexts). That makes it a parallel HTTP stack, not a complement, to Laravel's default. Laravel ships Guzzle 7 behind Illuminate\Support\Facades\Http; every Laravel idiom we rely on — Http::fake(), Http::retry(), request/response events, Telescope and Pulse integration, middleware for auth/logging/tracing — is bound to that client. Adopting YurunHttp means forking our outbound-HTTP layer away from the framework's grain. The only defensible architectural driver is non-blocking I/O under Swoole, i.e. Laravel Octane or a Hyperf/Swoole service where Guzzle's blocking sockets stall the event loop.

Integration feasibility. Feasible but all bespoke. There is no first-party Laravel service provider, facade, or config publishing; we would write the container binding, config, and a PSR-18 adapter ourselves. The package exposes its own request/response objects rather than PSR-7/PSR-18, so an adapter is mandatory if we want any portability back to Guzzle. Expect a spike of roughly 3–5 engineering days for a hardened wrapper plus parity tests, before any application code changes.

Technical risk — high, concentrated in supply chain, not code quality:

• Bus factor 1. Single maintainer (Yurunsoft), Chinese-language documentation, community support via a QQ group — not a channel our team or on-call rotation can use.
• Adoption signal is weak. 261 stars and zero Packagist dependents means almost no production usage to learn from; edge cases in TLS, redirects, proxies, multipart, streaming, and HTTP/2 will be ours to find.
• Release metadata anomaly. "Last release 2026-07-24" is a future date; treat the version timeline as unverified and confirm actual release cadence and changelog discipline before committing.
• Ecosystem gravity. Choosing this puts us off the road paved by Guzzle, Symfony HttpClient, and the coroutine-safe hyperf/guzzle bridge — meaning every future Laravel upgrade, HTTP RFC, or observability tool is a manual integration.
• Opportunity score of 18 is consistent with the above: the package solves a real problem (coroutine HTTP) but the market has already consolidated around alternatives.

Key questions for the maintainer/spike:

1. PSR-18 / PSR-7 compliance, or a documented adapter path?
2. Is the Curl and Swoole driver behaviour identical (retries, timeouts, redirects, cookies, error semantics), or are there silent divergences?
3. Is the client coroutine-safe and connection-pool-aware when reused across Octane workers? What are the lifetime/teardown rules?
4. Security disclosure policy, CVE history, and dependency footprint (does it pull in Swoole extensions or optional pecl deps)?
5. Maintenance commitment: release cadence, PHP version support policy, willingness to accept upstream patches from us?

Integration Approach

Stack fit. Poor-to-moderate for a conventional Laravel app; moderate for a Laravel Octane/Swoole or Hyperf service with demonstrably high outbound-call concurrency. Do not consider it for a standard FPM deployment — Guzzle is strictly better there on every axis.

Migration path. Do not migrate. Introduce behind a seam:

1. Define an internal HttpClient contract (or adopt PSR-18) that our code depends on.
2. Keep Guzzle as the default binding; register YurunHttp as an alternate implementation.
3. Bind via a service provider and toggle per-environment/per-call-site with a config flag.
4. Pilot on low-blast-radius traffic only: read-only third-party lookups, webhooks, non-transactional telemetry. Explicitly exclude payments, auth/token exchange, and anything on a critical path.
5. Only after a benchmark proves a material win do we widen the surface.

Compatibility. Verify against our actual PHP matrix first — the Curl driver is broadly portable, but Swoole support is pinned to specific Swoole/OpenSwoole versions and PHP releases. Confirm behaviour under Octane's worker lifecycle (long-lived process, no per-request global reset). Check that our logging/tracing middleware can wrap the adapter, since we lose Laravel's built-in HTTP events.

Sequencing. Two-week decision gate:

• Days 1–2: spike in a throwaway Octane service; confirm coroutine HTTP works.
• Days 3–5: benchmark p50/p95 latency and throughput vs. Guzzle under realistic concurrency; quantify the win (or the absence of one).
• Days 6–8: build the adapter + parity test suite (redirects, timeouts, retries, TLS, large payloads, error codes).
• Days 9–10: pilot one low-risk integration behind a flag; document a rollback plan.
• Exit criteria: a stated latency/throughput improvement with numbers, or we stop and stay on Guzzle / evaluate hyperf/guzzle.

Operational Impact

Maintenance. We inherit ownership of the glue: the Laravel provider, PSR-18 adapter, config, and parity tests. That is permanent internal surface area for a dependency the framework would otherwise maintain for free. A single-maintainer upstream also means we should budget for occasional patching ourselves — realistically, expect to vendor-fork the repo within 18 months if it goes quiet.

Support. Upstream support is a QQ group and Chinese-language docs; our on-call engineers cannot use either. Internal documentation and a named owner become mandatory, not optional. There is no commercial support tier and no realistic path to one.

Scaling. This is the entire justification, and it only pays off under Swoole: blocking Guzzle calls serialise an Octane worker, so a service making 10 parallel upstream calls at 100 ms each burns ~1 s of worker time versus ~100 ms with a coroutine client. If our profile doesn't show that pattern at volume, the benefit is theoretical. Under FPM there is zero scaling upside — each request gets a process either way.

Failure modes to plan for:

• Event-loop stall — any accidental blocking call (filesystem, DB, sync log) inside a coroutine context defeats the whole point; hard to detect without instrumentation.
• Connection-pool exhaustion / fd limits under high fan-out, with error semantics that differ from Guzzle's.
• Observability blind spot — losing Http::fake(), HTTP client events, and Telescope/Pulse coverage degrades testability and incident diagnosis.
• Silent behavioural drift — redirect/timeout/TLS handling differing from Guzzle, discovered in production rather than in test.
• Upstream abandonment — no patch for a CVE or a broken PHP minor, with no fallback but the shared interface we built.

Ramp-up. Moderate. The API is simple and chainable, so day-one productivity is fine; the real cost is teaching the team when it is safe to use (coroutine context only, never mixing with blocking calls) and building the tribal knowledge that would normally come from a large community. Budget half a day of team enablement plus the adapter walkthrough.

TPM recommendation. Do not adopt as a general replacement for Guzzle. Approve a time-boxed spike only, gated on a measured Octane concurrency problem and a working rollback. Absent that measurement, the risk-adjusted case for taking on a single-maintainer, zero-dependent dependency in our outbound-HTTP path is not there — the score of 17.6 and opportunity score of 18 reflect that correctly.