Curl Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound HTTP plumbing. The package bundles two capabilities: an HttpKernel implementation that dispatches a Symfony Request over cURL, and a facade over PHP's ext-curl including curl_multi_*. The decision it informs is whether to standardize outbound calls on a thin, self-owned wrapper versus pulling in Guzzle/Symfony HttpClient or writing bespoke cURL code per service.
• Service-to-service call strategy. The HttpKernel-over-cURL trick lets a remote service be invoked as if it were a local subrequest ($kernel->handle($request)), which supports decisions about internal API composition, edge aggregation, and whether remote calls should share the controller/middleware lifecycle of local routes.
• Fan-out architecture for read-heavy endpoints. curl_multi support is the real product lever: dashboards, search aggregation, BFF/API-gateway endpoints, and batch enrichment jobs where wall-clock latency is dominated by N sequential round-trips. This is a concrete argument for parallel fetch over a queue-and-poll design at low-to-moderate request volumes.
• Dependency footprint policy. A zero-Guzzle, zero-PSR-18 option matters where dependency review is expensive, extension availability is guaranteed, or a security team restricts third-party HTTP stacks.
• Roadmap scoping for legacy modernization. Most realistic use is as a reference implementation when auditing or migrating an existing Symfony 2/3-era integration — useful to price out "replace with HttpClient" work, not to justify new investment.
• Explicit non-decision for Laravel. Despite being grouped with PHP/Laravel packages, this is a Symfony Bundle (it registers via the Symfony kernel and depends on HttpKernel). It offers no Laravel service provider or facade, so it should not enter a Laravel build-vs-buy comparison at all.

When to Consider This Package

Consider it when:

• You are maintaining an existing Symfony 2.x/3.x application that already depends on it, and a rip-and-replace is not justified by current risk tolerance.
• You need highly concurrent outbound GET/POST calls and have a hard constraint against adding Guzzle, Symfony HttpClient, or any PSR-18 implementation.
• You specifically want the "remote call as a kernel subrequest" ergonomic, and you are willing to own the code.
• Your team is comfortable with ext-curl semantics (handles, options, curl_multi loops) and will write its own tests around the facade.

Look elsewhere when:

• You are on a modern Symfony version. Use symfony/http-client (native concurrency via HttpClientInterface, AsyncResponse, retry, and PSR-18 compliance) or Guzzle's Pool/promises.
• You are building on Laravel. Use the HTTP client facade or Guzzle; there is no Laravel integration here.
• You need PSR-7/PSR-18 interop, middleware, streaming, HTTP/2, or first-class mocking in tests.
• Supply-chain and maintenance risk are scored: 13 stars, 0 dependents, a single-author namespace, and no evidence of ongoing compatibility maintenance. Treat it as unmaintained until proven otherwise.
• You need security guidance for TLS/proxy configuration, or an audited dependency for a regulated environment.
• Your concurrency need is high enough that you want connection pooling, backoff, and circuit breaking — none of which a raw curl_multi facade gives you.

Adoption gate (recommended): require a spike proving it runs on your target Symfony version, a written owner, and a migration path to Symfony HttpClient within two quarters. If any of those is missing, decline.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that does two things — it lets one Symfony app call another as though it were a local request, and it exposes PHP's built-in parallel HTTP capability so pages that need many remote calls can fetch them at once instead of one after another. It is not a strategic dependency: 13 stars, zero known downstream projects, one author, no Laravel support, and no visible maintenance cadence. Recommendation: do not adopt for new development. Fund the equivalent behavior on Symfony's first-party HTTP client, which is roughly one to two engineer-days of work and carries none of the bus-factor risk. Keep this package only where it is already in production, with a named owner and a scheduled migration.

For engineering: The curl_multi facade is the only genuinely useful piece; the HttpKernel-over-cURL trick is clever but couples remote calls to local request semantics and is easy to reimplement with HttpClient + RequestStack. Cost of replacement is low precisely because the abstraction surface is small — which is also why keeping it is not worth defending. Standardize on symfony/http-client (or Guzzle where already present), and if you want the subrequest ergonomic, build a thin adapter on top rather than inheriting an unmaintained bundle.

For product/roadmap owners: Treat any feature that "needs" this as needing parallel outbound I/O — that requirement is real and worth scheduling. The package itself is an implementation detail; do not let a 13-star dependency become a roadmap constraint or an excuse to defer the platform-standard migration.