React Adapter Laravel Package

Product Decisions This Supports

• Build vs. buy (transport layer): this package is thin glue, not a platform. The real decision is whether we standardize outbound HTTP behind PSR-18 / HTTPlug interfaces so we can swap transports (Guzzle, cURL, ReactPHP) without touching call sites. Adopting this is the cheap "borrow" side of that decision — MIT-licensed, one dependency.
• Architecture for long-running PHP: if the roadmap includes ReactPHP-based daemons, websocket servers (e.g., Ratchet), or event-loop workers, this lets us reuse existing HTTPlug/SDK code asynchronously instead of maintaining a second client stack.
• Latency/throughput feature work: enables non-blocking fan-out (parallel calls to several internal services), streaming and long-poll consumption in CLI services — an "async capability" we can schedule without a framework migration.
• Vendor neutrality: many third-party SDKs type-hint Http\Client\HttpClient; this keeps them portable across transports and reduces lock-in to Guzzle.
• Scope discipline: only worth scheduling if a concrete service already runs an event loop. Otherwise it's invisible plumbing with no user-facing output.
• Read the signals: 19 stars, last release November 2022, opportunity score 0.38 — treat this as a low-investment utility, not a strategic dependency. Do not anchor roadmap commitments to it.

When to Consider This Package

Consider it when:

• You already run a ReactPHP event loop in the process — no loop, no value.
• You need non-blocking/concurrent outbound HTTP in a long-running CLI, daemon, or worker — not in typical FPM request/response.
• You depend on libraries requiring HTTPlug/PSR-18 clients and want them to operate asynchronously without forking them.
• You want to keep HTTPlug middleware (logging, retry, auth plugins) in front of an async transport.
• Your team understands promises, loop blocking, and async error propagation — async bugs are subtle and expensive.

Look elsewhere when:

• You're doing standard Laravel HTTP handling — use Laravel's HTTP client (Guzzle) or Symfony HttpClient. Note Laravel Octane is Swoole/RoadRunner, not ReactPHP; this adapter gives you nothing there.
• You're on amphp or Swoole — use their native clients rather than bridging ReactPHP.
• You need active maintenance, security response SLAs, or a large community. Last release Nov 2022 and ~19 stars means assume you may own patches.
• You can standardize purely on PSR-18 — react/http isn't PSR-18 native; a plain PSR-18 client may be the shorter path.
• You need streaming, HTTP/2, or pooling guarantees — validate react/http capabilities directly rather than trusting the adapter.

If adopted: pin the version, wrap it behind your own client interface, and keep a synchronous fallback.

How to Pitch It (Stakeholders)

Executive summary: a small, free (MIT) adapter that lets our PHP services make outbound HTTP calls concurrently on an event loop without rewriting existing client code or replacing SDKs. The business value is backend latency and throughput — fewer serial round-trips, cheaper fan-out — not a customer-facing feature. Cost is low and contained: one dependency, no license fee, no infrastructure. Risk is maintenance: the package is small and quiet (last release 2022, roughly 19 stars), so we should treat it as thin glue we're prepared to patch or replace, isolate it behind our own client interface, and avoid making it load-bearing for the platform. Recommendation: approve for a scoped pilot in one event-loop service, measure p95 and concurrency gains, and revisit if we standardize on Swoole/amphp or if maintenance lapses.

For engineering: it bridges HTTPlug to react/http, so PSR-18/HTTPlug-consuming code gets an async transport; avoid blocking calls inside the loop, handle promise rejection paths explicitly, and load-test before rollout.