anlutro/curl
anlutro/curl is a simple, chainable cURL wrapper for PHP and Laravel. It offers an intuitive interface for GET/POST requests, headers, cookies, redirects, timeouts, and error handling, making HTTP calls cleaner and easier to test than raw cURL.
Architecture fit. anlutro/curl is a thin, framework-agnostic object wrapper over ext-curl (cURL request builder + cURLResponse value object). It sits at the same layer as Guzzle and, critically, Laravel's own Http facade — which has shipped in-framework since Laravel 7 and is itself Guzzle-backed. For a standard Laravel application this is a capability overlap, not a gap-filler: adopting it means maintaining a second HTTP egress path alongside the native client. Its legitimate fit is narrow — a small, dependency-light service (or a legacy/non-Laravel PHP component inside a monorepo) where pulling Guzzle's dependency tree is genuinely unwanted, or where a team already standardizes on its $curl->get()/post() API. It has no PSR-18/PSR-7 compliance, no async/concurrency primitives, and no middleware/interceptor model, so it does not compose with the broader PHP HTTP ecosystem.
Integration feasibility. Mechanically trivial: composer require anlutro/curl, ext-curl is already present in virtually every PHP image, and there is no framework coupling. If the package does not ship a Laravel service provider/auto-discovery for your target version, you write a ~15-line provider binding cURL as a singleton and optionally a facade — low effort, but it is bespoke code your team now owns. The real feasibility question is testability: the class instantiates curl handles internally, so unit-testing call sites without live sockets requires wrapping it behind your own interface and mocking that.
Technical risk. Low intrinsic complexity (small, readable surface area, MIT, single-purpose) but non-trivial sustainability and standards risk. Dependents count is reported as zero, which is a weak adoption signal — expect to be largely self-supporting on edge cases (redirects, streaming, multipart, proxy, TLS). Bus factor is effectively one maintainer. Absence of PSR compliance means an eventual swap to Guzzle/Symfony HttpClient is a call-site refactor unless you abstract now.
Key questions.
Illuminate\Support\Facades\Http or Guzzle? What concrete constraint (dependency weight, legacy code, existing convention) justifies a third HTTP path?HttpClient interface so the dependency is replaceable?Stack fit. Compatible with any PHP 7/8 runtime with ext-curl; no Laravel version coupling either way. Confirm the composer.json PHP constraint against our lowest-supported runtime before committing — a Dec 2025 release is a good signal of active PHP 8 support but should be verified, not assumed.
Migration path. Do not adopt as a greenfield default. Two viable paths: (a) containment — use it only inside a single adapter class implementing our own HttpClient port, so it never leaks into domain code; (b) consolidation — if the goal is reducing HTTP client sprawl, the correct move is the opposite direction: standardize on Laravel Http/Guzzle and port any existing anlutro/curl call sites to it. If legacy code already uses this package, wrap-then-strangle: introduce the port, delegate to cURL, and swap the implementation later without touching callers.
Compatibility. No PSR-18/PSR-7 interoperability, so it cannot participate in framework-agnostic middleware, retry decorators, or recording/mocking libraries built on those standards. Response objects are package-specific value objects (->body, ->statusCode, ->headers) — mapping to our DTOs is manual. Cookie handling, redirects, and multipart are configured via raw curl options, which means option drift across call sites unless centralized in the adapter.
Sequencing. (1) Confirm the constraint that rules out the native client and document it. (2) Verify PHP constraint, license, and release cadence; run a dependency/license scan. (3) Build the HttpClient port + adapter with a fixed, opinionated default option set (timeouts, TLS verification, redirects, user agent, retry policy). (4) Pilot on one low-risk outbound integration behind a feature flag. (5) Only then expand; keep the adapter as the sole import site so exit cost stays at one file.
Maintenance. Minimal code to maintain but a single-maintainer dependency with no dependents — treat upstream as best-effort. Budget for the possibility of vendoring/forking a small class. Our own glue (provider, adapter, defaults, tests) becomes the real maintenance surface, and it is small enough to be acceptable.
Support. Community-only: GitHub issues, no commercial backing, no security response process we can point auditors at. For a package that touches outbound network and TLS, absence of a documented disclosure channel is a governance gap to record in the risk register.
Scaling. Synchronous, blocking, one-handle-per-request by default — fine for low-to-moderate outbound volume, poor for high-fan-out or latency-sensitive paths. No built-in connection pooling, concurrency, or async; parallel calls require rolling our own curl_multi or a queue/worker pattern. If outbound throughput is a growth axis, this is the wrong primitive and should be flagged now rather than after adoption.
Failure modes. Errors surface as exceptions on curl-level failures, but HTTP 4xx/5xx are not exceptions — callers must inspect statusCode explicitly, a common source of silently swallowed errors. Unset timeouts are the sharpest operational risk: a hung third party can pin PHP-FPM workers, so connect/read timeouts must be enforced in the adapter defaults, not left to call sites. No native retry/backoff or circuit breaking; those must live in the adapter or surrounding layer. TLS verification defaults and proxy behavior should be asserted with a test, not assumed.
Ramp-up. Very low — the API is small and self-evident, and a mid-level engineer is productive in under an hour. The learning cost is not the package; it is the internal convention we impose around it (defaults, error mapping, testing seam), which is where onboarding documentation must focus.
How can I help you explore Laravel packages today?