Http Laravel Package

Technical Evaluation

Architecture fit. wandu/http is a standalone, framework-agnostic HTTP toolkit that overlaps almost entirely with what a modern Laravel application already ships: Symfony HttpFoundation for request/response abstraction, the Illuminate\Http\Client wrapper around Guzzle for outbound calls, and Illuminate\Support\Arr/GuzzleHttp\Psr7\Query for header and query-string handling. It is "PSR-friendly" rather than PSR-7/PSR-17/PSR-18 compliant, which means it does not slot into the standard middleware and client-interop ecosystem. Architecturally this is a parallel implementation of solved problems, not a gap-filler — the integration would add a second, divergent HTTP abstraction layer alongside Laravel's native one.

Integration feasibility. Low. There is no Laravel service provider, config file, facade, or published configuration, so any integration is bespoke glue code we would own. The package was last released 2016-09-20 and the repository is archived, so its Composer constraints were authored for PHP 5.x/7.0-era runtimes. Laravel 9+ requires PHP 8.0, Laravel 10 requires 8.1, and Laravel 11/12 require 8.2+; the likelihood that composer require resolves cleanly against a current Laravel composer.json is poor, and forcing it with --ignore-platform-reqs would be an immediate blocker in review. The repository link is reported as unknown, which also prevents provenance and code review.

Technical risk. High, and concentrated in unmaintained code rather than in runtime complexity. The package has 17 stars and a composite score of 0.1025 — negligible adoption means no community triage of edge cases and no downstream bug reports to learn from. An archived 2016 codebase will not have been exercised against PHP 8.x deprecations (dynamic properties, implicit nullable parameters, string-offset syntax), modern TLS defaults, or PSR-7 v2 interfaces. There is no security response process, so any CVE would go unpatched and our composer audit would remain silent — absence of advisories here reflects absence of attention, not absence of defects. The largest risk is not the package itself but blast radius: an abandoned dependency with a hard PHP ceiling can block an entire platform upgrade.

Key questions.

• Which specific capability is missing from Illuminate\Http\Client, Symfony HttpFoundation, and a PSR-18 client that justifies adding this dependency?
• Is the intended use server-side request representation, outbound client calls, or both? The answer determines whether the replacement is HttpFoundation, Guzzle/PSR-18, or both.
• Does any existing code already import the Wandu\Http namespace, and if so, how large is the call-site surface?
• Can we obtain and review the source, and are we prepared to fork and permanently own it if we proceed?
• What are the package's defaults for timeouts, redirects, TLS verification, and header parsing, and do they match our security baseline?

Integration Approach

Stack fit. Poor as an addition, adequate as a replacement target. Every advertised feature maps to a maintained first-party or de facto standard component:

Migration path. Treat this as a strangler-fig replacement, not an adoption. Step one is inventory: run static analysis (PHPStan/Larastan) and a namespace grep for Wandu\Http to enumerate call sites and identify the actual surface in use. Step two is characterization: write tests that pin current observable behavior — header casing and multi-value handling, query encoding of nested arrays and booleans, redirect and error semantics — before changing anything, because these are exactly the details that break silently during a swap. Step three is a seam: if call sites are numerous, introduce a thin internal interface (e.g. App\Contracts\HttpTransport) with the wandu/http implementation behind it, then replace the implementation with the native client and delete the dependency. If the package is not yet in the codebase, skip steps two and three entirely and standardize on the native stack.

Compatibility. Assume incompatibility until proven otherwise. Verify PHP constraint against our runtime, confirm whether PSR-7 v1 or v2 interfaces are expected, and check for conflicts with Guzzle 7 and Laravel's locked Symfony component versions. Test on the lowest and highest PHP versions in our support matrix. There is no Laravel version matrix to consult, so the compatibility verdict has to be produced by our own CI rather than inherited from the maintainer.

Sequencing.

1. Discovery and call-site inventory; quantify the surface.
2. Decision gate: adopt native primitives vs. build an internal adapter (default: native).
3. If a seam is required, introduce the internal interface and wrap existing behavior; land characterization tests.
4. Replace implementation behind the interface, module by module, with parallel-run comparison on header/query edge cases.
5. Remove wandu/http from composer.json and add a CI guard (dependency policy check plus composer audit) so it cannot reappear.
6. Document the decision in an ADR so future contributors do not rediscover the package and re-evaluate it.

Operational Impact

Maintenance. Effectively total ownership transfer. Archived means no bug fixes, no PHP-version bumps, no dependency updates, and no release cadence to plan around. If we adopt, we must fork, vendor, and staff it — a permanent tax on a component that provides commodity functionality. Upstream will never absorb a patch we submit.

Support. No maintainer, no issue triage, and a 17-star community that cannot substitute for support. Documentation is a single short description with no API reference, so onboarding depends on reading source. Internal escalation paths must be defined before adoption, not after the first production incident.

Scaling. Runtime characteristics are unlikely to be the constraint — the library is small and dependency-light. The operational scaling concerns are behavioral: unclear defaults for connection reuse, timeouts, and retries can cause PHP-FPM worker exhaustion under load when an upstream service degrades, and there is no async/concurrent request support for fan-out workloads. Laravel's HTTP client provides explicit timeout, retry, and pooling controls that we would otherwise have to build.

Failure modes.

• Upgrade deadlock: a hard PHP constraint in an abandoned package blocks Laravel/PHP upgrades for the whole application; high likelihood, high impact, low detectability until upgrade time.
• Silent behavioral drift: header normalization, multi-value headers, redirect following, and query encoding differ from the native stack, producing bugs that surface only against specific upstream services.
• Security blind spot: unpatched TLS/redirect/header-parsing behavior with no advisory channel; composer audit reports clean, creating false assurance.
• Dependency resolution failure: CI breaks on a clean install, or requires --ignore-platform-reqs, which then masks real platform mismatches elsewhere.
• Knowledge concentration: the one engineer who wired the adapter leaves, and the bespoke glue becomes unowned.

Ramp-up. Learning the API is a day; the real cost is verification and exit. A team can integrate it quickly, which is precisely the trap — the expense arrives later as audit findings, upgrade blockers, and a forced migration under time pressure. Budget the replacement effort up front and skip the intermediate state.

Recommendation. Do not adopt wandu/http. Standardize on Laravel's HTTP client plus Symfony HttpFoundation for new work, and treat any existing usage as technical debt to be retired behind an adapter seam within a defined window. If a legacy constraint forces temporary use, time-box it, isolate it behind an internal interface, and attach an explicit removal ticket with an owner.