Http Client Laravel Package

Product Decisions This Supports

• Feature feasibility — concurrent outbound I/O. Any feature that fans out to many upstream services in one request (BFF/aggregation endpoints, search federation, pricing/availability lookups, AI model routing) becomes viable in PHP without serial latency stacking. This is the difference between an endpoint that takes p95 = N × upstream_latency and one that takes roughly max(upstream_latency).
• Architecture roadmap. The real decision it informs is the runtime migration: PHP-FPM request-per-process → Workerman/webman-style long-running workers. This client only pays off inside an event loop; adopting it is usually a downstream consequence of that migration, and a cheap forcing function to evaluate the migration's value.
• Build vs. buy vs. borrow.
  • Build a bespoke non-blocking client: rarely justified — that's a connection pool, DNS cache, chunked decoding, and timeout semantics you'd own forever.
  • Buy/managed (hosted gateway, HTTP proxy sidecar): justified when outbound calls need central retry/circuit-breaking/observability across languages.
  • Adopt OSS (this package): justified when you're already on Workerman, want zero C extensions, and need pooling + concurrency more than middleware richness.
  • Alternative OSS: Guzzle + CurlMultiHandler (best ecosystem, works in FPM), Symfony HttpClient (mature, PSR-18, good retry/streaming), Swoole/OpenSwoole clients (faster, heavier ops burden).
• Capacity and cost planning. Connection reuse and concurrency reduce the worker count and memory ceiling needed per node for I/O-bound services. This feeds the infra sizing model and the "do we need more pods or a different runtime?" conversation.
• Use-case shortlist for discovery/validation: webhook and notification dispatch, third-party API enrichment, proxy/passthrough endpoints, fan-out read models, scheduled crawlers and pollers, internal service-to-service calls with strict tail-latency budgets.
• Risk posture decision. 55 stars and zero dependents is a governance input, not a product one: it argues for an internal HttpClient interface plus an adapter, so the product bet is "we can make concurrent outbound calls" rather than "we bet the roadmap on workerman/http-client."

When to Consider This Package

Adopt when most of these hold:

• The service already runs on Workerman or a Workerman-derived stack (webman, GatewayWorker, custom Worker daemons) and has a live event loop to hook into.
• The workload is I/O-bound fan-out: N+1 upstream calls per inbound request, or high-volume small requests (webhooks, notifications, enrichments).
• You need concurrency without installing ext-swoole / ext-openswoole — pure PHP is acceptable and often preferable for container portability and shared hosting parity.
• You want connection pooling and keep-alive for free, with per-request timeouts and a coroutine/fiber-style call style that reads like synchronous code.
• Latency tail (p95/p99) is a tracked SLO and serial outbound calls are the dominant contributor.
• Your team can reason about event loops, fibers, and shared mutable state across requests.

Look elsewhere when:

• You're on stock PHP-FPM / mod_php. There is no ambient event loop; Guzzle or Symfony HttpClient is the correct default and has orders of magnitude more community support.
• You need a PSR-18 / PSR-7 contract, or must swap clients per environment (testing, mocking, vendor abstraction). This package is not PSR-standardized — plan on your own adapter.
• You need mature middleware: retries with backoff, circuit breakers, rate limiting, request signing, OpenTelemetry tracing hooks. Guzzle/Symfony or a service mesh sidecar gives you this out of the box; here you'd write it.
• You depend on HTTP/2 multiplexing, HTTP/3, or fine-grained TLS/proxy configuration.
• Support and longevity matter more than fit. 55 stars, 0 dependents, and a single-maintainer profile mean no commercial support, thin StackOverflow coverage, and a real bus-factor. If this sits on a revenue path, that's a fork-and-vendor decision, not an adoption decision.
• The concurrency need is low (a handful of calls, or a batch job where a queue and workers already solve it). Adding an event loop to save 200ms is not worth the operational novelty.

Mitigation if you do adopt: wrap it behind a narrow internal interface on day one; pin versions; add contract tests with a stub server; budget a small amount of engineering time to track upstream releases rather than assuming passive maintenance.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, focused library that lets our PHP services make many outbound HTTP calls at the same time instead of one after another. For any customer-facing feature that aggregates data from several internal or partner APIs, it directly compresses response time and reduces the number of servers we need to run — a latency and infrastructure-cost play, not a new platform. The strategic caution is maturity: the project is early-stage and thinly adopted, so we will isolate it behind our own interface, which keeps the switch-out cost low and the product bet on "faster fan-out," not on this specific library. Recommend a scoped pilot on one non-critical fan-out endpoint before any broader commitment.

To engineering:

• Pure-PHP, no ext-swoole; integrates natively with Workerman's event loop, connection pooling and keep-alive included.
• Fiber/coroutine-style API — code reads sequentially while executing concurrently; explicit per-request timeouts.
• Trade-off accepted: no PSR-18, no built-in retry/circuit-breaker/observability. We own that layer.
• Mandatory: adopt only in Workerman-hosted services, behind an internal HttpClient port with a Guzzle-backed adapter for FPM contexts and tests.
• Please return findings on: tail-latency delta vs. serial Guzzle, connection-reuse behavior under load, error/timeout semantics, and any memory growth in long-running workers.

To product/roadmap: Green-light scope: fan-out and enrichment endpoints in event-loop services. Red-light scope: anything in the critical checkout path until the pilot clears, and anything requiring an event-loop runtime we don't already operate.