Psr 18 Guzzle Adapter Laravel Package

Product Decisions This Supports

• The real decision is "standardize on PSR-18," not "adopt this package." The package is a thin wrapper (essentially a single class implementing Psr\Http\Client\ClientInterface around GuzzleHttp\Client). It is the enabler for a strategic decision: making HTTP transport an interface in your codebase rather than a concrete Guzzle dependency. Treat the package as an implementation detail of that decision, and weigh the two separately.
• Vendor lock-in reduction / migration optionality. Every service class that type-hints GuzzleHttp\Client is a future migration cost. Type-hinting ClientInterface preserves the option to swap in Symfony HttpClient, php-http/guzzle7-adapter, or a native client later without rewriting business logic — valuable if you have API-heavy services (integrations, webhooks, partner APIs) on the roadmap.
• Testability as a feature investment. PSR-18 gives you one seam to double in tests instead of mocking Guzzle's fluent surface and handler stack. If HTTP-dependent code is currently under-tested or flaky in CI, this is a cheap, high-leverage quality improvement that pairs well with Laravel's Http::fake() for the Laravel-native client and PSR-18-level fakes for legacy Guzzle paths.
• Build vs. buy: here, "build" is a genuine option. A PSR-18-to-Guzzle adapter is on the order of tens of lines. With 9 stars, 0 dependents, a single maintainer, and an LGPL-3.0 license requiring legal review, the rational PM call for most teams is write the adapter internally (MIT, ~1 file, 20 lines of tests) while keeping the architectural standard. Adopting the package is defensible only if you want zero-maintenance ownership and are comfortable with the bus factor.
• Enables a phased refactor roadmap. Concrete sequencing: (1) bind ClientInterface in the container, (2) migrate new code and new API clients to PSR-18, (3) migrate existing service classes opportunistically, (4) decide on middleware/retry/async gaps. This is a low-risk background track that rarely needs dedicated sprint capacity.
• Clarifies where Guzzle's feature surface is load-bearing. Guzzle-specific behavior — async promises, TransferStats, retry/backoff middleware, on_stats hooks — is not exposed through PSR-18. This surfaces an honest inventory question: which of your services genuinely depend on Guzzle semantics versus merely using Guzzle's API?

When to Consider This Package

Consider it when:

• You already depend on Guzzle and have a meaningful amount of code or third-party libraries type-hinting ClientInterface (or you want them to).
• You are modernizing a legacy Laravel codebase toward interface-driven HTTP while keeping Guzzle underneath — i.e., you want the abstraction without a transport rewrite.
• You are introducing PSR-15 middleware, PSR-17 factories, or PSR-7 message handling and want the client to sit consistently in that stack.
• Your architecture documents (modular monolith, service extraction, multi-vendor API integrations) already commit to interchangeable HTTP clients.

Look elsewhere or build in-house when:

• Governance is a blocker. LGPL-3.0 requires legal/compliance sign-off in many organizations. For a wrapper this small, an internally owned MIT implementation removes both the license review and the maintainer-risk conversation.
• You are on a fresh Laravel app. Laravel's Http facade is already PSR-18-compatible and better integrated (fakes, retries, logging, events). Adding a Guzzle adapter to a greenfield project is net new surface area for no gain.
• You are not on Guzzle. The adapter is a no-op value proposition.
• You depend on Guzzle-only semantics. Async request batching, custom handler stacks, or TransferStats-based observability will force you back to GuzzleHttp\Client or a bespoke wrapper anyway.
• You need long-term support guarantees. 9 stars, 0 dependents, a solo maintainer, and release notes that are almost entirely changelog links (including a v2.0.0 that is only a rename) is a weak signal for anything load-bearing. Budget for a fork.

Not a fit at all: high-throughput services where you would benchmark client overhead, or teams without PSR-18 familiarity and no plan to build it.

How to Pitch It (Stakeholders)

Executives (30 seconds): "We have a small architectural choice in front of us with outsized long-term value: make our HTTP layer depend on a standard interface instead of one vendor library. It costs a few days of incremental refactoring across existing code and zero runtime overhead. The payoff is that when we need to change HTTP clients — for a migration, a vendor constraint, or a performance reason — it's a config change, not a rewrite across every integration. The package under discussion is a 20-line wrapper; the decision that matters is the standard, not the dependency. Recommendation: adopt the standard, and implement the adapter in-house under MIT rather than taking a dependency on a 9-star, single-maintainer, LGPL-licensed wrapper."

Engineering: "Adopt Psr\Http\Client\ClientInterface as the type-hint for all HTTP dependencies and bind a Guzzle-backed adapter in AppServiceProvider. Two constraints to accept up front: PSR-18 exposes a subset of Guzzle (no async promises, no TransferStats, no middleware stack), and GuzzleException needs normalizing to ClientExceptionInterface at the boundary. Both are tractable; neither disappears by adopting the third-party package. Given the package's size and support profile, the low-risk path is to vendor a small internal adapter with its own tests — same architectural benefit, no license review, no bus-factor exposure."

Architects: "This is a sequencing decision, not a feature. Bind the interface first, migrate new code as it's written, and refactor existing clients opportunistically — never as a big-bang. Gate the refactor on one honest inventory: which services truly need Guzzle-specific capabilities (async, retry middleware, transfer stats) versus merely use Guzzle. Anything in the first bucket stays on the concrete client behind a narrow, documented exception. The interface becomes the default; the concrete client becomes a deliberate, visible escape hatch."